:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
HTTPS!!!!1!!1!1!1!1!2!
Wat als nu een Iraanse staatshacker m'n stem verandert met een MITM-aanval?
🠕 This side up
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Maar dat is niet waar:
[...]
Wel mooi ook dat 'ie in 20 jaar ofzo niet veranderd is
.edit: waardeloos dat ie nog steeds geen valide cert heeft. Nu cached de tweakers http proxy het resultaat.
[ Voor 14% gewijzigd door .oisyn op 01-10-2020 11: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.
/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/195618/mp3smiley.jpg?f=community)
Oehh, dit mag niet volgens de algmene voorwaarden:
[...]
Maar dat is niet waar
[Afbeelding]
[Afbeelding]
[Afbeelding]
[Afbeelding]
[Afbeelding]
.edit: waardeloos dat ie nog steeds geen valide cert heeft. Nu cached de tweakers http proxy het resultaat.
Ook fijn dat het nog steeds een beta-versie is.quote: http://poll.dezeserver.nl/
Ik heb de poll niet gemaakt, ik ben nooit akkoord gegaan met die voorwaarden:
Oehh, dit mag niet volgens de algmene voorwaarden
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.
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
Dat is zoals Google, die brengen hun producten ook enkel in beta uit
(Gmail was ook héél lang "beta"). 
:strip_exif()/u/80759/monstermania_small.gif?f=community)
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Ben wel benieuwd. Hoeveel polls 403005, hoeveel stemmen.:
Wel mooi ook dat 'ie in 20 jaar ofzo niet veranderd is
Beetje statistieken. Standaard deviatie, normaalkromme, mediaan.....
Vragen vragen vragen.
If money talks then I'm a mime
If time is money then I'm out of time
/u/262310/ava.png?f=community)
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Er is maar één goede tip mogelijk, dus laten die maar gelijk geven.:
[...]
Een goed vaag verhaal voor een eigen topic
Ruwe SQL ondersteund geen "opmaak". Het verwerkt alleen data. Wil je opmaak, dan zul je een andere tool moeten gebruiken zoals exporteren naar CSV en dan in bijv. Excel of Calc je opmaak regelen.
Next
Sinds de 2 dagen regel reageer ik hier niet meer
:strip_icc():strip_exif()/u/116600/crop5be04a1ae3ded_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
Als je leest wat hij wil is het niet wat ik denk dat jij denkt dat opmaak is.:
[...]
[...]
Er is maar één goede tip mogelijk, dus laten die maar gelijk geven.
Ruwe SQL ondersteund geen "opmaak". Het verwerkt alleen data. Wil je opmaak, dan zul je een andere tool moeten gebruiken zoals exporteren naar CSV en dan in bijv. Excel of Calc je opmaak regelen.
Next
Maar het vervangen van een stuk tekst door spaties.
Anyways een apart topic is het beste.
/u/105842/Homer_60x60.png?f=community)
/u/613048/crop5db7e8da13e77.png?f=community)
Am I a joke to you?:
[...]
[...]
Er is maar één goede tip mogelijk, dus laten die maar gelijk geven.
Ruwe SQL ondersteund geen "opmaak". Het verwerkt alleen data. Wil je opmaak, dan zul je een andere tool moeten gebruiken zoals exporteren naar CSV en dan in bijv. Excel of Calc je opmaak regelen.
Next
Ik snap je wel hoor, maar met FORMAT, PIVOT en GROUP BY GROUPING SETS kan je resultaten op zich best nog wel toonbaar maken om even snel een berekening met (sub)totalen te tonen en je geen zin hebt om te exporteren naar Excel.
/u/86654/crop68d4ff30987a8.png?f=community)
:fill(white):strip_exif()/f/image/DC6HZQEReUnDKwvpDPvMH8QF.png?f=user_large)
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
:strip_exif()/u/737473/crop65ba9e759f7c0_cropped.webp?f=community)
:strip_icc():strip_exif()/u/136527/ovide2.jpg?f=community)
Als programmeur van industriële productielijnen kan ik me die frustratie van de operator goed voorstellen.
Heb zelf wel eens meegemaakt dat er vaak een zelfde onterecht alarm optrad binnen een machine waardoor de boel stopte en dus de operator naar het controlepaneel moest komen, op de reset knop drukken en vervolgens op de start knop. Toen we op locatie waren bleek het ineens minder erg te zijn, bleek dat de operator een tandenstoker tussen de reset knop geklemd had zodat het alarm direct gereset werd en de machine niet stopte.
Toch maar het daadwerkelijke probleem opgelost, en de reset knop aangepast dat die enkel werkt op een transitie van 0 naar 1
Heb zelf wel eens meegemaakt dat er vaak een zelfde onterecht alarm optrad binnen een machine waardoor de boel stopte en dus de operator naar het controlepaneel moest komen, op de reset knop drukken en vervolgens op de start knop. Toen we op locatie waren bleek het ineens minder erg te zijn, bleek dat de operator een tandenstoker tussen de reset knop geklemd had zodat het alarm direct gereset werd en de machine niet stopte.
Toch maar het daadwerkelijke probleem opgelost, en de reset knop aangepast dat die enkel werkt op een transitie van 0 naar 1
...
:strip_icc():strip_exif()/u/211322/crop5ec3dbce66fdb.jpeg?f=community)
Doet me denken aan die aflevering van air crash investigation waar bleek dat piloten de zekering losdraaide van een alarm wat constant afgaat als je op de grond bent en een bepaalde handeling (die niet heel direct nodig was) nog niet had gedaan.
Dat bleek echter ook een ander alarmcircuit van spanning te voorzien, en uiteraard was dat circuit een keer nét nodig om piloten te waarschuwen voor een noodsituatie
Dat bleek echter ook een ander alarmcircuit van spanning te voorzien, en uiteraard was dat circuit een keer nét nodig om piloten te waarschuwen voor een noodsituatie
/u/147751/avatar455992_1.gif.png?f=community){kind=avatar}
Als je eens wist hoe lang het soms duurt voordat de programmeur het echte probleem van de gebruiker kan/mag zien.
Meestal gaat dat via een leidinggevende die er een eigen draai aan geeft, of het probleem helemaal niet door geeft. Of je hebt eindelijk eens rechtstreeks contact met de eindgebruiker en er komt ineens met een complete waslijst voorbij met wat er allemaal nog meer mankeert aan het systeem en dat ook nog nooit is doorgegeven.
Meestal gaat dat via een leidinggevende die er een eigen draai aan geeft, of het probleem helemaal niet door geeft. Of je hebt eindelijk eens rechtstreeks contact met de eindgebruiker en er komt ineens met een complete waslijst voorbij met wat er allemaal nog meer mankeert aan het systeem en dat ook nog nooit is doorgegeven.
Speel ook Balls Connect en Repeat
We hebben bij zachte oplevering bij sommige klanten direct contact gezocht met de mensen op de vloer en aan hen een staat meegegeven met vragen en plek voor opmerkingen om zo meer te weten te komen dan "Hij doet het niet". Waar je dan vaak achter komt is dat mensen soms onbegrijpelijke dingen doen als iets bijvoorbeeld net een halve seconde te laat reageert of iets niet 100% volgens verwachting loopt.
In de staat stonden invulregels zoals 'wat trof je aan', 'beschrijf het probleem', 'wat heb je geprobeerd om het op te lossen', 'welke uitwerking had je oplossing', 'is het probleem verholpen', 'wat heb je gedaan om het te verhelpen' en dergelijke.
Dan kom je er dus achter dat er best veel mensen op de vloer denken dat een stekker ergens uittrekken en er dan weer instoppen een storing verhelpt.
In de staat stonden invulregels zoals 'wat trof je aan', 'beschrijf het probleem', 'wat heb je geprobeerd om het op te lossen', 'welke uitwerking had je oplossing', 'is het probleem verholpen', 'wat heb je gedaan om het te verhelpen' en dergelijke.
Dan kom je er dus achter dat er best veel mensen op de vloer denken dat een stekker ergens uittrekken en er dan weer instoppen een storing verhelpt.
/u/286895/icon1.png?f=community)
Dat denken veel mensen omdat dat ook gewoon zo is.:
Dan kom je er dus achter dat er best veel mensen op de vloer denken dat een stekker ergens uittrekken en er dan weer instoppen een storing verhelpt.
Heeft geen speciale krachten en is daar erg boos over.
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
Is dat niet het hele idee van Kubernetes? Gewoon fokking veel pods lanceren die elkaar opvangen?:
[...]
Dat denken veel mensen omdat dat ook gewoon zo is.
Engineering is like Tetris. Succes disappears and errors accumulate.
Na 1 keer bij de Appie een tijd gewacht te hebben tot zo'n tiener de stekker van de sap-hannes-machine eruit ragt, doe ik het in het vervolg wel zelf bij storing:
Dan kom je er dus achter dat er best veel mensen op de vloer denken dat een stekker ergens uittrekken en er dan weer instoppen een storing verhelpt.
Je hebt storing en je hebt ‘storing’ en om bij live draaiende windows machines de stekker er uit te trekken omdat een synchronisatie nog niet klaar is bijvoorbeeld… sja
Tsja windows ... met z'n ik ga wel updaten waar het jou het vervelendste uit komt en ga dan miepen dat je de stekker er niet uit mag raggen, mis maar lekker de trein terwijl je naar m'n hypnotiserende ronddraaiende animated gifje kijkt, zodat illuminati bill gates de zoveelste je kan beinvloeden, 1984 .. windows 1995, Willem 11 .. zie de verbanden .. of zoiets. Het script voor m'n nieuwe sekte is nog een WIP
Maar goed de meeste meuk werkt toch met een microcontroller en heeft geen ramen, dus daar werkt de methode "Jolande Sap" heel goed. Zeker dus bij Sap-pers-machines, die daar naar vernoemd zijn, althans dat is dan mijn aanname
Maar goed de meeste meuk werkt toch met een microcontroller en heeft geen ramen, dus daar werkt de methode "Jolande Sap" heel goed. Zeker dus bij Sap-pers-machines, die daar naar vernoemd zijn, althans dat is dan mijn aanname
[ Voor 21% gewijzigd door gekkie op 03-10-2020 19:39 ]
Oh ja het advies ‘have you tried turning it off & on again?’ heb ik ook echt wel eens gegeven maar voor 99,9999% van de storingen heb ik niet voor niets een GUI gebouwd op een dedicated controller die zelfstandig computers, lampen, deuren, rolluiken, alarmen, projectoren, audio servers, speakers en what not netjes uit zet danwel reboot.
Game developers krijg ik maar niet zo verzon games op Linux of PLC’s te schrijven al heb ik zelf ook al zat games gemaakt mét plcs maar dat waren games met fysieke controllers en fysieke interface ipv een spiffy scherm-game
Game developers krijg ik maar niet zo verzon games op Linux of PLC’s te schrijven
al heb ik zelf ook al zat games gemaakt mét plcs maar dat waren games met fysieke controllers en fysieke interface ipv een spiffy scherm-game
Maar heb je dan ook een dedicated controller die de dedicated controller reset mocht dat nodig zijn? En eentje daarvoor? etc.
Meestal zet je twee dezelfde controllers neer; een master en een slave. De slave doet niks anders dan wachten tot de master omvalt.
Maar ik heb ook wel eens twee verschillende (soorten) controllers met elkaar laten babbelen (in een low cost project); de ene stuurde zijn current settings (on change per belangrijke verandering, dus geen bulk) naar de andere en vice versa. Dit werd in een array gezet in beide apparaten. Gewoon in RAM.
Als er eentje omvalt en weer online komt vraagt hij eerst wat zijn laatste settings zijn aan het andere device en in welke stand het andere device staat. Een bijzonder functionele workaround in de praktijk, zolang de fout dus zit in één van die devices (In ieder geval met twee devices in dezelfde MER op twee verschillende sloffen.)
Maar ik heb ook wel eens twee verschillende (soorten) controllers met elkaar laten babbelen (in een low cost project); de ene stuurde zijn current settings (on change per belangrijke verandering, dus geen bulk) naar de andere en vice versa. Dit werd in een array gezet in beide apparaten. Gewoon in RAM.
Als er eentje omvalt en weer online komt vraagt hij eerst wat zijn laatste settings zijn aan het andere device en in welke stand het andere device staat. Een bijzonder functionele workaround in de praktijk, zolang de fout dus zit in één van die devices
(In ieder geval met twee devices in dezelfde MER op twee verschillende sloffen.)
[ Voor 8% gewijzigd door Wilf op 05-10-2020 19:37 ]
Nou, 'fokking veel' weet ik niet (meeste van onze services draaien er gewoon 2) maar hard 'crashen' als er iets echt mis is, is wel een best practice ja. Dan wordt er gewoon een nieuwe pod gestart en ondertussen wordt het verkeer naar de andere pods geroute.:
Is dat niet het hele idee van Kubernetes? Gewoon fokking veel pods lanceren die elkaar opvangen?
Het is wel belangrijk om pod restarts in je dashboarding weer te geven. Het is over 't algemeen een goeie indicatie dat er echt iets mis is.
https://niels.nu
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
Nouja, het kan an sich wel. Voor een secundaire database of cache is het prima. Maar een primaire productie database, vooral iets als Postgres of MSSQL, is zo gebonden aan de node waarop het draait dat het gewoon weinig zin heeft.:
Dat weerhoudt dan weer niet iedereen er van
Maar ik heb sowieso weinig met bedrijven die zelf on-prem k8s gaan draaien. Ik zit nu (nog) bij een klant waar alles bij Google staat, en dus is het daar gewoon een kwestie van CloudSQL in je project hangen waarna je k8s services gewoon netjes met je DB (in ons geval Postgres) praten. Laat het ops werk maar door Google doen, die zijn er over 't algemeen een stuk beter in.
https://niels.nu
:strip_icc():strip_exif()/u/393369/crop55d593566408c.jpeg?f=community)
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Een paar keer per maand weigert mijn laptop in hibernation te gaan. Hij lockt, gaat uit en (volgens de event log) een seconde later weer aan. De troubleshooter blijft keer op keer beweren dat alles in orde is behalve de helderheid van mijn scherm want die past toch echt niet bij mijn energieprofiel 
Bedankt troubleshooter, echt heel behulpzaam.
En dan werkt hibernation een dag later opeens weer dus dan stop ik weer met zoeken naar de oorzaak.
Ooit op een andere laptop wel met powercfg oid erachter gekomen dat een proces voorkomt dat hij in hibernation gaat maar die nuttige info moet je veertig lagen diep zoeken.
Bedankt troubleshooter, echt heel behulpzaam.En dan werkt hibernation een dag later opeens weer dus dan stop ik weer met zoeken naar de oorzaak.
Ooit op een andere laptop wel met powercfg oid erachter gekomen dat een proces voorkomt dat hij in hibernation gaat maar die nuttige info moet je veertig lagen diep zoeken.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
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.
Ik zie hier echt veel Laravel fanboys, terwijl dat framework toch echt zuigt.
Geen Symfony devvers hier?
Geen Symfony devvers hier?
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
Want, mening?:
Ik zie hier echt veel Laravel fanboys, terwijl dat framework toch echt zuigt.
Geen Symfony devvers hier?
Ik zie hier vooral veel mensen die PHP überhaupt niet serieus nemen.:
Ik zie hier echt veel Laravel fanboys, terwijl dat framework toch echt zuigt.
Geen Symfony devvers hier?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/174665/crop5f3505845c31b_cropped.jpeg?f=community)
:strip_exif()/u/47168/loop.gif?f=community)
Weinig frameworks zijn zo uitgesproken in hun stijltje als Laravel, dus er zit alleen maar meer een richting in. Maar het is wel goed mogelijk dat dat stijltje niet de jouwe is.
Juist dat het zo ‘opionated’ is, is een kracht. Ze gaan voor fanatieke fans ipv een iets grotere doelgroep op alle manieren te pleasen.
Maar goed, daarom werkt deze troll ook zo goed op de vrijdagmiddag.
Juist dat het zo ‘opionated’ is, is een kracht. Ze gaan voor fanatieke fans ipv een iets grotere doelgroep op alle manieren te pleasen.
Maar goed, daarom werkt deze troll ook zo goed op de vrijdagmiddag.
{signature}
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Dat woord fanboy is echt zo giftig. Alsof een afkeur alleen verklaard kan worden doordat anderen niet onafhankelijk, objectief en nuchter kunnen nadenken en er onmogelijk afwegingen zijn die in het voor- of nadeel uitvallen van een bepaalde keuze.
Ouderwets gevalletje van de man in plaats van de bal spelen. Dat terwijl een onderbouwde rant tegen Laravel juist heel leuk zou zijn om te lezen. Of tegen Symphony. Of whatever. Het gaat om de rant, niet om het framework
Maar, zoals @farlane zegt ja, goed uitgevoerde troll.
Ouderwets gevalletje van de man in plaats van de bal spelen. Dat terwijl een onderbouwde rant tegen Laravel juist heel leuk zou zijn om te lezen. Of tegen Symphony. Of whatever. Het gaat om de rant, niet om het framework
Maar, zoals @farlane zegt ja, goed uitgevoerde troll.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Holala, we hebben hier een fanboy van het woord "fanboy":
Dat woord fanboy is echt zo giftig. Alsof een afkeur alleen verklaard kan worden doordat anderen niet onafhankelijk, objectief en nuchter kunnen nadenken en er onmogelijk afwegingen zijn die in het voor- of nadeel uitvallen van een bepaalde keuze.
Ouderwets gevalletje van de man in plaats van de bal spelen. Dat terwijl een onderbouwde rant tegen Laravel juist heel leuk zou zijn om te lezen. Of tegen Symphony. Of whatever. Het gaat om de rant, niet om het framework
Maar, zoals @farlane zegt ja, goed uitgevoerde troll.
.
In Javaland is de boel ook wel aardig op de kop gegooid. Waar voorheen een trage release schedule was met pakweg 4-5 jaar public support (en nog wel een stuk langer support voor mensen met een support contract), heb je nu enerzijds meer JDK aanbieders naast (voohreen) Sun / (nu) Oracle, maar anderzijds ook eens in de zoveel jaar weer een LTS release, met daartussen releases met nieuwe features die niet LTS zijn en pakweg een jaartje support hebben.
Op zich is men in Javaland ook nog wel weer behoorlijk conservatief in de zin dat de changes niet dusdanig breaking zijn dat je nauwelijks kunt upgraden. Het meest vervelende bij upgrades van Java <9 naar een versie hoger dan 9 is dat je voor een aantal zaken die standaard in de JDK zaten nu externe dependencies moet importeren.
Hoe langer je wacht, des te vervelender het wel wordt natuurlijk. Mag nog gezellig een vrij groot project gaan overbouwen naar cloud native vanuit logge on premise JBoss servers (ja, al lang uit de LTS) op een java versie die ook al lang uit de LTS is en qua code bestaat uit fantastisch onderhouden, niet gedocumenteerde procedurele brei doorspekt met 20 niveau's diep geneste control structures en loops.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/3106/crop601874b34ff83_cropped.png?f=community)
Lees hier een mogelijke reden dat je software niet oneindig lang gaat ondersteunen.:
Hoe langer je wacht, des te vervelender het wel wordt natuurlijk. Mag nog gezellig een vrij groot project gaan overbouwen naar cloud native vanuit logge on premise JBoss servers (ja, al lang uit de LTS) op een java versie die ook al lang uit de LTS is en qua code bestaat uit fantastisch onderhouden, niet gedocumenteerde procedurele brei doorspekt met 20 niveau's diep geneste control structures en loops.
'Moeten we niet naar de nieuwste versie gaan?'
'Nee joh, ondersteuning is nog tot 2024, we kijken over een paar jaar wel.'
Ergens in 2026: 'Het hele systeem werkt niet meer en we moeten nu naar de nieuwste versie!'
'Eeuhm ja leuk, maar 95% van je code is bagger. Wacht nog een (x aantal) jaar en dan is het wel opnieuw gemaakt.'
Precies, voor "levende" software vind ik een relatief korte LTS-periode helemaal niet zo slecht. Het zou iemand (anders dan de devs) ook meer incentive moeten geven om de boel bij de tijd houden. Doorgaans willen de devs wel vanwege alle nieuwe goodies, maar "geen security updates meer" is ook voor andere mensen nog wel eens een motivatie.
Nu lag het bij bovenstaand stuk software net zo hard aan de devs die zo bang zijn voor nieuwe dingen (wordt dan geen software developer, denk ik dan) dat er ook nooit moeite is gestoken in enige vorm van technologische vernieuwing. Die devs upgraden wordt de komende tijd nog net zo'n klus als de software.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/81985/crop566b00b43645a.png?f=community)
En geen generics na type erasure, en dus geen zaken als generics in throwables.:
[...]
Zoals covariant arrays?
Een hele redenering waarom multiple inheritance géén goed idee is en dat ze dat echt niet gaan ondersteunen, en het dan stiekem toch ondersteunen in de vorm van uit de klauwen gegroeide interfaces. Stiekem is dat natuurlijk geen legacy-probleem want ze kunnen morgen zeggen 'joh, we hebben eigenlijk al een slap aftreksel van multiple inheritance, dus waarom dan ook niet.
En, euhm, null. Als je een taal gewend bent wat goede alternatieven heeft voor null, dan zijn null-pointer exceptions echt ruk. Java is statisch getypeerd, behalve null.
[ Voor 27% gewijzigd door bwerg op 10-10-2020 20:23 ]
Heeft geen speciale krachten en is daar erg boos over.
Daarover verschillen we van mening. Wanneer ik het heb over backwards compatibility, dan bedoel ik niet dat je elk half jaar 2 tot 6 uur ergens aan moet sleutelen. Dan wil ik eigenlijk de oude code 1-op-1 over kunnen nemen. Ik heb geen probleem met de invulling van het upgradepath, maar met het feit dat er (zo vaak) een upgradepath nodig is.
Voorbeeldje: .NET Framework 3.5 SP 1 komt uit 2008, en heeft basisondersteuning tot 2029. Nu is dat allicht een beetje extreem, maar ik vind een half jaar dan ook weer erg kort
[ Voor 9% gewijzigd door Koenvh op 10-10-2020 23:58 ]
🠕 This side up
Java heeft dan Optional geïntroduceerd om nog iets van expliciete null-checking af te dwingen, maar het blijft behelpen. Ik zie dat dat ook maar matig wordt begrepen. Gaan mensen parameters van type optional definiëren met het idee dat het dan null-safe zou zijn. Helaas, nullpointer op je Optional.map.
De JVM heeft natuurlijk wel een aantal vrij serieuze Java-alternatieven. Kotlin kent bijvoorbeeld wel weer nullable en non-nullabe types.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik zou eerder zeggen dat mensen die null in optionals gaan stoppen of null als waarde van een optional gebruiken het niet hebben begrepen, dan de mensen die, best wel terecht, aannemen dat men dat gewoon niet moet doen.:
[...]
Java heeft dan Optional geïntroduceerd om nog iets van expliciete null-checking af te dwingen, maar het blijft behelpen. Ik zie dat dat ook maar matig wordt begrepen. Gaan mensen parameters van type optional definiëren met het idee dat het dan null-safe zou zijn. Helaas, nullpointer op je Optional.map.
Dat is nou een gevalletje legacy-meuk. Je kan wel Optionals en nullable-annotaties gaan toevoegen, maar zodra je tegen een stuk code gaat aanpraten waar dingen niet mooi geannoteerd of ge-optional'd zijn, dan kom je toch niet meer onder het onhandige gedrag van null uit.
Heeft geen speciale krachten en is daar erg boos over.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik ben ook geen voorstander van dat het element null onderdeel maakt van elk referentietype, maar het ging me wat ver om dan maar aan te geven dat null niet statisch getypeerd is.
Ja, het standaard beschikken over een Maybe/Nullable/Optional/etc. typeconstructor maakt het leven beter, maar daar beschikt Java ook over (zoals al boven mij is aangekaart). Op een ander vlak is Java explicieter, waarbij een subset aan exceptions expliciet dienen te worden gemaakt.
(Nog beter zou imho een Either typeconstructor zijn
)Ja, het doet het concept van behavioral subtyping teniet, waar o.a. Liskov een voorstander van is. Maar goed, op dat gebied is Java zeker niet sterk (e.g. de eerder genoemde covariant arrays, maar ook dingen als java.util.Stack<E>).
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Het punt is niet de aanwezigheid van een Option type, maar de type checks op null values. In Java kan je null pointer exceptions krijgen op elk reference type, in C# en TypeScript geeft de compiler je netjes een error als een reference null kan zijn en mag je null niet toekennen aan een reference type (behalve als die expliciet nullable is). Je hebt eigenlijk ook helemaal geen Option type nodig voor null safety,:
[...]
Ja, het standaard beschikken over een Maybe/Nullable/Optional/etc. typeconstructor maakt het leven beter, maar daar beschikt Java ook over (zoals al boven mij is aangekaart). Op een ander vlak is Java explicieter, waarbij een subset aan exceptions expliciet dienen te worden gemaakt.
(Nog beter zou imho een Either typeconstructor zijn
code:
is conceptueel niet anders dan 1
| None | Some a |
code:
, zolang je taal geen vreemde subtyping doet met null. Anders is het allebei gewoon een a+1 type.
1
| null | a |
Nou, niet echt. Als je een functie plus noemt kun je ook wel klagen dat degene die dat aanroept wel moet controleren of de functie wel echt optelt en toch niet stiekem aftrekt, maar als ik al mijn aannames over code die ik niet zelf heb geschreven moet gaan checken, dan ben ik wel even bezig... Laat staan dat dat een argument is om de functie dan maar niet plus te noemen.
Optional wordt gebruikt om null te voorkomen en niet anders. Het alternatief is dat je echt letterlijk overal en altijd alles null-checkt. Wordt ik helemaal gek van. Vijf argumenten, eerst 10 regels boilerplate
code:
1
2
3
4
5
| if (x == null)
jaWatDanEigenlijk();
if (y == null)
throw new RuntimeException("Waarom doe je dit met null, daar kan ik helemaal niks mee");
... |
En dan roept die methode weer een gelijknamige methode aan die bijna hetzelfde is maar dan met een extra argument, en wat ga je daar dan doen? Weer allemaal null-checks? Zo blijf je bezig.
Ik dus niet. De 'typeringsregel' dat null elk type is, doet in feite gewoon niks wat met typering te maken heeft. Net zo min als de typeringsregel dat een appel een banaan is. Een null-check (impliciet door de JRE bij het aanroepen van een methode) is gewoon een dynamische typecheck.:
maar het ging me wat ver om dan maar aan te geven dat null niet statisch getypeerd is.
[ Voor 16% gewijzigd door bwerg op 11-10-2020 11:22 ]
Heeft geen speciale krachten en is daar erg boos over.
/u/56000/neuken.png?f=community)
Dan heb je denk ik een oudere versie?
:fill(white):strip_exif()/f/image/rcNx2kzOqAFai54p8upmsxdA.png?f=user_large)
Uit luiheidsoverwegingen vaak alleen op de public API, in je interne classes binnen je package kan je er vaak wel vanuit gaan dat je alles hebt afgevangen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Er is nog een extra probleem met Optional. Bijvoorbeeld, je hebt een publieke API met functie getZipCode die een Optional teruggeeft. De functie werkt op dit moment alleen nog voor een bepaald aantal straten, en anders krijg je een empty terug. Een aantal versies later pas je de functie aan waardoor het voor alle straten werkt, en je geen Optional meer nodig hebt.
Dan moet je dus of je publieke API aanpassen, of een Optional teruggeven die altijd een waarde heeft. Beide zijn niet geweldig. Met null heb je dat probleem niet*.
* Met null heb je alleen twintig andere problemen
Dan moet je dus of je publieke API aanpassen, of een Optional teruggeven die altijd een waarde heeft. Beide zijn niet geweldig. Met null heb je dat probleem niet*.
* Met null heb je alleen twintig andere problemen
[ Voor 5% gewijzigd door Koenvh op 11-10-2020 14:25 ]
🠕 This side up
Alle straten hebben bestaat niet, want als ik een staat verzin bestaat die sowieso niet.:
Er is nog een extra probleem met Optional. Bijvoorbeeld, je hebt een publieke API met functie getZipCode die een Optional teruggeeft. De functie werkt op dit moment alleen nog voor een bepaald aantal straten, en anders krijg je een empty terug. Een aantal versies later pas je de functie aan waardoor het voor alle straten werkt, en je geen Optional meer nodig hebt.
Dan moet je dus of je publieke API aanpassen, of een Optional teruggeven die altijd een waarde heeft. Beide zijn niet geweldig. Met null heb je dat probleem niet*.
* Met null heb je alleen twintig andere problemen
Ook komen er steeds straten bij. Vraag maar aan mensen in nieuwbouwwijken hoe frustrerend online shoppen kan zijn.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Slecht voorbeeld dan, maar mijn punt blijft hetzelfde:
[...]
Alle straten hebben bestaat niet, want als ik een staat verzin bestaat die sowieso niet.
Ook komen er steeds straten bij. Vraag maar aan mensen in nieuwbouwwijken hoe frustrerend online shoppen kan zijn.
🠕 This side up
In een API documenteren dat null inmiddels niet meer voor komt is lelijk maar eigenlijk een luxe probleem. Een API breken omdat iets uiteindelijk nullable moet zijn is een stuk stommer.
{signature}
Maak een nieuwe methode die het object direct teruggeeft, en verander de oude methode zodat die de nieuwe wrapt in een optional. Deprecate de oude.
Nu nog het return-type onderdeel van de method signature laten zijn zodat de oude en nieuwe methode ook daadwerkelijk dezelfde naam kunnen hebben en de vlag mag uit.
Heeft geen speciale krachten en is daar erg boos over.
Ah ja, de befaamde getZipCode2:
[...]
Maak een nieuwe methode die het object direct teruggeeft, en verander de oude methode zodat die de nieuwe wrapt in een optional. Deprecate de oude.
Nu nog het return-type onderdeel van de method signature laten zijn zodat de oude en nieuwe methode ook daadwerkelijk dezelfde naam kunnen hebben en de vlag mag uit.
🠕 This side up
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
In de stijl van PHP realGetZipCode:
[...]
Ah ja, de befaamde getZipCode2
“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.”
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.
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
Dit topic is gesloten.