[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Over uitlaatklep gesproken.. ik zit bij een klant waar ze eigen "IT" hebben die volledig bestaat uit types die zonder enige inhoudelijke kennis willen "aansturen". Nou heb ik ze een half jaar geleden proberen uit te leggen dat je met het einde van een groot migratietraject in zicht niet weer een of ander megalomaan doelarchitectuurstokpaardje moet gaan opstarten. Ik gaf aan dat wat ze voor ogen hadden minimaal 5 jaar zou gaan duren en hoogst onzeker was in plaats van de voorgeschotelde 6 maanden. Werd afgeserveerd als ononderbouwd onderbuikgeneuzel. Inmiddels zijn we een jaar verder, is 10% van het project gerealiseerd en zijn de running costs niet de in mijn oplossing geschatte 10k per jaar, maar 1,5 miljoen. Om over een totaal gebrek aan performance en dergelijke nog maar te zwijgen. Graag gedaan hoor.armageddon_2k1 schreef op vrijdag 19 april 2024 @ 17:28:
De devschuur is een uitlaatklep en geen vraagbaak ;-) Maar ik zal eens een topicje eraan wagen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Haha, nou ik hoop het niet meer mee te maken hoor.Marc3l schreef op vrijdag 19 april 2024 @ 18:57:
Lekker toch, nog 9 jaar werk 😛
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ach ja. Ik heb wel vaker meegemaakt dat men liever een herbouw wil doen, dan het huidige systeem bij te werken. Vaak is dat eigenlijk een verkapte "dan kan ik leuke dingen doen en het goed doen" en "ik wil niet aan het oude systeem werken" dan om het systeem echt te verbeteren. Op mijn vorig project ook; nieuwbouw/herbouw en 'nu wel goed'. Mijn team had toen ook een aantal punten aangedragen dat het geen goed idee was en dat een plan miste. Allemaal geneuzel, doomdenken of foutief volgens hun. Toch kon je een tijdje later elk punt van het lijstje afstrepen. Maar men leert er niet van.Mugwump schreef op vrijdag 19 april 2024 @ 18:37:
[...]
Over uitlaatklep gesproken.. ik zit bij een klant waar ze eigen "IT" hebben die volledig bestaat uit types die zonder enige inhoudelijke kennis willen "aansturen". Nou heb ik ze een half jaar geleden proberen uit te leggen dat je met het einde van een groot migratietraject in zicht niet weer een of ander megalomaan doelarchitectuurstokpaardje moet gaan opstarten. Ik gaf aan dat wat ze voor ogen hadden minimaal 5 jaar zou gaan duren en hoogst onzeker was in plaats van de voorgeschotelde 6 maanden. Werd afgeserveerd als ononderbouwd onderbuikgeneuzel. Inmiddels zijn we een jaar verder, is 10% van het project gerealiseerd en zijn de running costs niet de in mijn oplossing geschatte 10k per jaar, maar 1,5 miljoen. Om over een totaal gebrek aan performance en dergelijke nog maar te zwijgen. Graag gedaan hoor.
Jammer. Wat dat betreft is softwareontwikkeling vrij vaag en niet echt te bevatten voor hoger management. Daarom wordt er vaak ook niet tegenin gegaan. De overheid had ooit een organisatie opgericht om softwareprojecten te beoordelen. Maar die had blijkbaar te vaak kritiek, waardoor het is opgeheven en er een afgezwakte Bureau ICT-Toetsing (BIT) voor in de plaats is gekomen.
let the past be the past.
Uhm... zitten we bij dezelfde klant?Mugwump schreef op vrijdag 19 april 2024 @ 18:37:
[...]
Over uitlaatklep gesproken.. ik zit bij een klant waar ze eigen "IT" hebben die volledig bestaat uit types die zonder enige inhoudelijke kennis willen "aansturen". Nou heb ik ze een half jaar geleden proberen uit te leggen dat je met het einde van een groot migratietraject in zicht niet weer een of ander megalomaan doelarchitectuurstokpaardje moet gaan opstarten. Ik gaf aan dat wat ze voor ogen hadden minimaal 5 jaar zou gaan duren en hoogst onzeker was in plaats van de voorgeschotelde 6 maanden. Werd afgeserveerd als ononderbouwd onderbuikgeneuzel. Inmiddels zijn we een jaar verder, is 10% van het project gerealiseerd en zijn de running costs niet de in mijn oplossing geschatte 10k per jaar, maar 1,5 miljoen. Om over een totaal gebrek aan performance en dergelijke nog maar te zwijgen. Graag gedaan hoor.
Herbouw is bijna nooit het antwoord. Het is namelijk bijna altijd onbegrip van de huidige oplossing en een utopisch toekomstbeeld die hiertoe leidt.SPee schreef op vrijdag 19 april 2024 @ 20:04:
[...]
Ach ja. Ik heb wel vaker meegemaakt dat men liever een herbouw wil doen, dan het huidige systeem bij te werken.
Nog steeds relevant: https://www.joelonsoftwar...u-should-never-do-part-i/
Met als belangrijke outtakes:
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
[ Voor 33% gewijzigd door armageddon_2k1 op 19-04-2024 20:57 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Zou kunnen, maar ik vrees eerder dat dit heel gangbaar is bij grote bedrijven en overheidsinstanties.
Overigens was dit in beide gevallen 'herbouw', belangrijkste motivatie hier was meer dat de verantwoordelijkheid voor de oplossing dan weer onder een ander poppetje geschoven kon worden.Maar ja legacy maatwerksoftware vervangen door een low code achtige oplossing in welke vorm dan ook is altijd vragen om problemen, tenzij je echt heel duidelijk kunt afbaken wat je wel / niet meeneemt aan functionaliteit en het proces aanpast op de mogelijkheden van de software ipv andersom.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Echter zit je al snel naar vele jaren werk te kijken waarbij je twee systemen moet onderhouden. Klanten verwachten dat het nieuwe beter is en alle oude functionaliteit beschikbaar blijft.
Een ander probleem in mijn ervaring is dat het nieuwe onderaan de prioriteiten lijst blijft hangen voor iedereen die er niet direct bij betrokken is. Daarnaast vatten de mensen die vele jaren aan het oude hebben gewerkt het persoonlijk op (begrijpbaar) en vertrekken soms ruim voordat het nieuwe live staat.
Dat was ook het eerste waar ik aan dacht, toen de architect kwam met "we gaan een herbouw doen".armageddon_2k1 schreef op vrijdag 19 april 2024 @ 20:55:
[...]
Herbouw is bijna nooit het antwoord. Het is namelijk bijna altijd onbegrip van de huidige oplossing en een utopisch toekomstbeeld die hiertoe leidt.
Nog steeds relevant: https://www.joelonsoftwar...u-should-never-do-part-i/
[...]
Dat laatste was ook een beetje het geval. Vijf jaar ontwikkelt en 2 jaar in productie. Maar de meeste developers van het eerste uur waren alweer weg en daarmee ook de diepgaande kennis van de code, architectuur en gedachte erachter. Met een "max 2 jaar voor externe consultants" krijg je dat al vrij snel (en anders willen die consultants na een aantal jaar ook weer wat nieuws). En als je dan niet weet waarom bepaalde keuzes zijn gemaakt, dan vraag je je als "nieuweling" vaak af waarom het zo gedaan is en of het niet beter kan. Misschien wel, misschien niet. Maar je moet dan wel de kennis opbouwen om de code te begrijpen en niet het makkelijk afdoen als "slechte code, herbouw nodig". Want over 3 jaar, denkt de volgende nieuwe ontwikkelaar hetzelfde over die nieuwe code.Kriekel schreef op zaterdag 20 april 2024 @ 15:31:
Het hangt helemaal van de situatie af of herbouw een goede keuze is. Heb je een complex systeem in een taal die niet of nauwelijks meer wordt onderhouden en waar je geen jonge programmeurs voor kunt vinden (cobol bijvoorbeeld) of een lowcode oplossing uit het jaar kruik dan is het een reële optie.
Echter zit je al snel naar vele jaren werk te kijken waarbij je twee systemen moet onderhouden. Klanten verwachten dat het nieuwe beter is en alle oude functionaliteit beschikbaar blijft.
Een ander probleem in mijn ervaring is dat het nieuwe onderaan de prioriteiten lijst blijft hangen voor iedereen die er niet direct bij betrokken is. Daarnaast vatten de mensen die vele jaren aan het oude hebben gewerkt het persoonlijk op (begrijpbaar) en vertrekken soms ruim voordat het nieuwe live staat.
let the past be the past.
Maar we hebben zojuist een enorme version update gedaan van een lading dependencies en daar zaten allemaal breaking changes in (BC in minor versie updates trouwens, thanks a lot). We hebben een test suite om e.e.a. uit te sluiten natuurlijk, maar ik kwam er wel achter dat het zonder een beetje compiler me bijna ondoenlijk lijkt.
Wat voor ervaring hebben mensen met grote version updates met breaking changes in echt dynamic talen (JS, Python, Clojure etc?). Is dat dan gewoon een kwestie van een kneitergrote test-suite tegenaan gooien?
Engineering is like Tetris. Succes disappears and errors accumulate.
Omdat de onderliggende taal geen typesystem heeft?armageddon_2k1 schreef op zondag 21 april 2024 @ 16:22:
(waarin je je af kan vragen of dat _echt_ typed is)
(Welke taal is dan wel echt typed?)
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ja.armageddon_2k1 schreef op zondag 21 april 2024 @ 16:22:
Wat voor ervaring hebben mensen met grote version updates met breaking changes in echt dynamic talen (JS, Python, Clojure etc?). Is dat dan gewoon een kwestie van een kneitergrote test-suite tegenaan gooien?
Als je geen types hebt dan moet je zowel tests als in je daadwerkelijke code types checken. Of compleet YOLO gaan, wat minder zeldzaam is dan je zou hopen.
Bij de laatste projecten waar ik aan heb gewerkt werden dependencies de hele tijd geupgrade. Dus als er dan wat omviel, dan was het de impact niet zo groot.armageddon_2k1 schreef op zondag 21 april 2024 @ 16:22:
Even een ander vraagje. Ik ben nogal fan van typed languages, maar op dit moment werken we aan een grote Typescript codebase (waarin je je af kan vragen of dat _echt_ typed is, maar soit).
Maar we hebben zojuist een enorme version update gedaan van een lading dependencies en daar zaten allemaal breaking changes in (BC in minor versie updates trouwens, thanks a lot). We hebben een test suite om e.e.a. uit te sluiten natuurlijk, maar ik kwam er wel achter dat het zonder een beetje compiler me bijna ondoenlijk lijkt.
Wat voor ervaring hebben mensen met grote version updates met breaking changes in echt dynamic talen (JS, Python, Clojure etc?). Is dat dan gewoon een kwestie van een kneitergrote test-suite tegenaan gooien?
Kun je dat niet beter doen? In groepjes upgraden ofzo?
Hoewel dat natuurlijk een goed idee is denk ik niet dat je ook daadwerkelijk minder werk verzet. Je moet links om rechtsom de impact van 'type' changes van de API's afvangen, ongeacht of je het nu in kleine of grote stappen doet.Kalentum schreef op zondag 21 april 2024 @ 16:40:
[...]
Bij de laatste projecten waar ik aan heb gewerkt werden dependencies de hele tijd geupgrade. Dus als er dan wat omviel, dan was het de impact niet zo groot.
Kun je dat niet beter doen? In groepjes upgraden ofzo?
Ik denk dat ie hint op programmeertalen met een compiler. Die dus niet geïnterpreteerde talen.RayNbow schreef op zondag 21 april 2024 @ 16:38:
Omdat de onderliggende taal geen typesystem heeft?
(Welke taal is dan wel echt typed?)
If money talks then I'm a mime
If time is money then I'm out of time
TypeScript is een gecompileerde taal.Matis schreef op zondag 21 april 2024 @ 16:45:
[...]
Ik denk dat ie hint op programmeertalen met een compiler. Die dus niet geïnterpreteerde talen.
If money talks then I'm a mime
If time is money then I'm out of time
Gecompiled? Of getranspiled (naar JavaScript, wat nog steeds "leesbare" code is, die nirt uitgevoerd kan worden maar weer door een interpreter/compiler gaat).
En TypeScript geeft AFAIK ook nog steeds voldoende mogelijkheden om buiten het typesystem te werken / "eender welk type" te gebruiken? IIRC met undefined type? Hetzelfde als dat je in C & C++ de void pointer hebt die je weer overal heen kunt casten onafhankelijk van of dat correct is.
[ Voor 18% gewijzigd door RobertMe op 21-04-2024 16:50 ]
Matis schreef op zondag 21 april 2024 @ 16:48:
Oh, tot zo ver mijn kennis over TS. Wordt dat dan gecompleteerd tot JavaScript ofzo?
TypeScript compile je met de tsc (TypeScript Compiler) naar javascript. Javascript is dan weer een geïnterpreteerd taal in de browser (maar kan ook weer gecompileerd worden naar van alles en nog wat). Dit is conceptueel niet anders dan je Java code naar een .jar compilen en die dan runnen met de java runtime. Of je C# compilen naar een DLL en die runnen met de dotnet runtime. En zeker in het geval van Java verlies je dan ook een hoop type informatie in de compile stap en is je runtime een stuk flexibler.RobertMe schreef op zondag 21 april 2024 @ 16:50:
[...]
Gecompiled? Of getranspiled (naar JavaScript, wat nog steeds "leesbare" code is, die nirt uitgevoerd kan worden maar weer door een interpreter/compiler gaat).
En TypeScript geeft AFAIK ook nog steeds voldoende mogelijkheden om buiten het typesystem te werken / "eender welk type" te gebruiken? IIRC met undefined type? Hetzelfde als dat je in C & C++ de void pointer hebt die je weer overal heen kunt casten onafhankelijk van of dat correct is.
Hoe high- of low-level de output code is heeft niets te maken met of een compiler een compiler is, een compiler is gewoon een ding wat van de ene taal naar de andere taal vertaald. Een transpiler vertaald binnen een taal en word vaak gebruikt voor optimalisaties en compatibiliteit.
En als we echt gaan mierenneuken dan is een taal niet gecompileerd of geinterpreteerd, dat is een implementatie detail van een implementatie van een taal. In principe kan je elke taal gecompileerd of geinterpreteerd maken, en voor de meeste populaire talen heeft ergens wel iemand zowel een compiler als een interpreter geimplementeerd.
Oh ik zou dat heel graag beter doen, maar ik heb dit project geeerfd en de vorige lead dev verbood mensen tests te schrijven en package upgrades te doen omdat het teveel tijd kostte en "je toch geen 100% dekking hebt".Kalentum schreef op zondag 21 april 2024 @ 16:40:
[...]
Bij de laatste projecten waar ik aan heb gewerkt werden dependencies de hele tijd geupgrade. Dus als er dan wat omviel, dan was het de impact niet zo groot.
Kun je dat niet beter doen? In groepjes upgraden ofzo?
Nu ik er een tijdje loop hebben we een lading tests erbij geschreven en zijn we nu weer helemaal up-to-date kwa updates.
Ik wil nu dus ook elk kwartaal de dependencies updaten. Ik kan wel zeggen dat het schier onmogelijk was geweest deze update uit te voeren zonder tests.
Maar het was puur uit interesse, want ik probeer altijd veel tests te hebben en vroeg me af hoe mensen dat doen in een groot project met dynamic taal. Zelf hou ik een stuk meer van static talen waar ik geen tests hoef te schrijven voor breaking changes in method calls, maar puur kan richten op de functionele tests.
EDIT: Wat betreft de Typescript compiler / transpiler whatever. De officiele Typescript compiler doet daadwerklijk aan type checking. Maar JS land zou JS land niet zijn als alles BLAZINGLY fast moet zijn, dus krijg je dingen als Vite en SWC en wat al niet meer. Die zijn inderdaad bloedje snel, maar doen geen type checking.
Dus dan heb je een prachtig React-Typescript project maar gaat de frontend kapot omdat Vite geen typechecking doet bij de built. Goed he? Oftewel, je bent React code aan het schrijven met alle mentale overhead van Typescript erbij, en het brengt je _niks_. Wij hebben nu een standaard typechecker pass in de pipeline zitten iig.
[ Voor 25% gewijzigd door armageddon_2k1 op 21-04-2024 17:13 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Een library die dus wijzigt en een breaking change introduceert komt er vanzelf wel uitrollen in de tests. En soms veranderen er dingen in die dependencies, maar hebben ze functioneel geen impact en ook geen impact op de performance en dan doen ze hun best maar.
We hebben iets dat heet Dependabot. Als er dan een nieuwe versie van iets uitkomt dan maakt 'ie automatisch een PR, runt de CI en wijst de PR toe aan iemand die dat ding dan reviewed (changelog bekijken, impact inschatten). Evt handmatig (als de test groen is) een paar smoke tests en klaar. Bij triviale changes (bv van een versie 1.3.4 naar 1.3.5) ben je vaak snel klaar. Zeker als je continiously deployment doet. Werkte prima. En als een upgrade meer werk opleverde dan werd er gewoon een ticket voor gemaakt en die werd dan ASAP ingepland.RagingPenguin schreef op zondag 21 april 2024 @ 16:44:
[...]
Hoewel dat natuurlijk een goed idee is denk ik niet dat je ook daadwerkelijk minder werk verzet. Je moet links om rechtsom de impact van 'type' changes van de API's afvangen, ongeacht of je het nu in kleine of grote stappen doet.
Nadeel van een hele zooi in 1 keer is dat je grote change sets hebt en als er dan 20 dingen omvallen dan is het even puzzelen om te kijken welke van de 60 upgrades daar de oorzaak van zijn.
Ik deal liever met 1 wijziging dan met 60.
Zelfs in PHP land zou je ‘vrij goed kunnen vertrouwen’ op de discipline bij Symfony en Doctrine dat ze geen semver fuckups of yolo momenten hebben. Dergelijke volwassen types zijn er niet bij JS/TS. Nee, ook niet React en nog wat projecten die zich heel netjes voordoen.
Uiteindelijk is dit allemaal gelul, want CI wil je hoe dan ook wel. Alleen de frequentie van verrassingen verschilt, maar deze zal nooit 0 zijn.
{signature}
Ben zelf backender en ik moet zeggen dat frontend vaak minder goede test coverage heeft. Maar ook de FE mensen upgraden liever 1 dependency dan een heleboel. Maar die vertrouwen meer op vaak deels nog niet geautomatiseerde tests. Good old handmatig testen dus.armageddon_2k1 schreef op zondag 21 april 2024 @ 17:05:
[...]
Oh ik zou dat heel graag beter doen, maar ik heb dit project geeerfd en de vorige lead dev verbood mensen tests te schrijven en package upgrades te doen omdat het teveel tijd kostte en "je toch geen 100% dekking hebt".
Nu ik er een tijdje loop hebben we een lading tests erbij geschreven en zijn we nu weer helemaal up-to-date kwa updates.
Ik wil nu dus ook elk kwartaal de dependencies updaten. Ik kan wel zeggen dat het schier onmogelijk was geweest deze update uit te voeren zonder tests.
Maar het was puur uit interesse, want ik probeer altijd veel tests te hebben en vroeg me af hoe mensen dat doen in een groot project met dynamic taal. Zelf hou ik een stuk meer van static talen waar ik geen tests hoef te schrijven voor breaking changes in method calls, maar puur kan richten op de functionele tests.
EDIT: Wat betreft de Typescript compiler / transpiler whatever. De officiele Typescript compiler doet daadwerklijk aan type checking. Maar JS land zou JS land niet zijn als alles BLAZINGLY fast moet zijn, dus krijg je dingen als Vite en SWC en wat al niet meer. Die zijn inderdaad bloedje snel, maar doen geen type checking.
Dus dan heb je een prachtig React-Typescript project maar gaat de frontend kapot omdat Vite geen typechecking doet bij de built. Goed he? Oftewel, je bent React code aan het schrijven met alle mentale overhead van Typescript erbij, en het brengt je _niks_. Wij hebben nu een standaard typechecker pass in de pipeline zitten iig.
Niet alle libraries gebruiken semantic versioning, TypeScript zelf bijvoorbeeld ook niet.armageddon_2k1 schreef op zondag 21 april 2024 @ 16:22:
(BC in minor versie updates trouwens, thanks a lot).
Patchversies zou doorgaans altijd wel zonder breaking changes moet kunnen, maar ook daar geen garanties natuurlijk.
Mijn Cypress tests geven me toch altijd wel iets van vertrouwen bij het doen van updates. Maar garanties krijg je nooit, dus release notes lezen blijft toch noodzakelijk.
De enige correcte aanpak imo is een volwassen test suite en CI pipeline en inderdaad iets als dependabot.
Mja compileren wordt in de volksmond toch vaak gezien als omzetten in machinecode. Java kent bijvoorbeeld in de basis JIT compilatie (behalve met GraalVM, die doet ook AOT) al wordt je geschreven code in het geval van JIT compilatie eerst nog vertaald naar Java bytecode.RagingPenguin schreef op zondag 21 april 2024 @ 17:01:
[...]
[...]
TypeScript compile je met de tsc (TypeScript Compiler) naar javascript. Javascript is dan weer een geïnterpreteerd taal in de browser (maar kan ook weer gecompileerd worden naar van alles en nog wat). Dit is conceptueel niet anders dan je Java code naar een .jar compilen en die dan runnen met de java runtime. Of je C# compilen naar een DLL en die runnen met de dotnet runtime. En zeker in het geval van Java verlies je dan ook een hoop type informatie in de compile stap en is je runtime een stuk flexibler.
Hoe high- of low-level de output code is heeft niets te maken met of een compiler een compiler is, een compiler is gewoon een ding wat van de ene taal naar de andere taal vertaald. Een transpiler vertaald binnen een taal en word vaak gebruikt voor optimalisaties en compatibiliteit.
En als we echt gaan mierenneuken dan is een taal niet gecompileerd of geinterpreteerd, dat is een implementatie detail van een implementatie van een taal. In principe kan je elke taal gecompileerd of geinterpreteerd maken, en voor de meeste populaire talen heeft ergens wel iemand zowel een compiler als een interpreter geimplementeerd.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
In mijn huidige project gebruiken we AWS CDK obv typescript en renovatebot voor automatische upgrades en idd volwassen tests. Dat laatste is nodig ook want er valt om de haverklap wat om.Caelorum schreef op zondag 21 april 2024 @ 17:30:
Semver vertrouw ik niet meer op. Zelfs in .net land met de grote partijen wil het nog wel eens fout gaan. In de afgelopen 5 jaar bijvoorbeeld al drie keer een breaking change gehad op een bugfix vanuit Microsoft.
De enige correcte aanpak imo is een volwassen test suite en CI pipeline en inderdaad iets als dependabot.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Tja, en wat noem je het ding wat je compilatie doet van Java naar Java bytecode, en waar zou die 'c' in javac Test.java toch voor staanMugwump schreef op zondag 21 april 2024 @ 17:59:
[...]
Mja compileren wordt in de volksmond toch vaak gezien als omzetten in machinecode. Java kent bijvoorbeeld in de basis JIT compilatie (behalve met GraalVM, die doet ook AOT) al wordt je geschreven code in het geval van JIT compilatie eerst nog vertaald naar Java bytecode.
[ Voor 3% gewijzigd door RagingPenguin op 21-04-2024 20:00 ]
Dus ik beschouw TS nu meer als een soort veredelde JS linter die net even iets meer type safety geeft (vooral binnen je eigen code), maar het voordeel zit m voor mij in de fijnere syntax en features als generics enzo.
[ Voor 18% gewijzigd door F.West98 op 22-04-2024 03:17 ]
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Tuurlijk... zo houdt Java's Stack zich niet aan het LSP-principe en zijn arrays in Java en C# ten onrechte covariant.F.West98 schreef op maandag 22 april 2024 @ 03:16:
Dat zijn toch zaken die je in meer "traditioneel" typed languages eigenlijk zelden tegenkomt.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
In welk opzicht eigenlijk niet?RayNbow schreef op maandag 22 april 2024 @ 04:24:
[...]
Tuurlijk... zo houdt Java's Stack zich niet aan het LSP-principe
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 heb heel erg het idee dat ik nu aan het happen ben)
Ja, als je een javascript library gebruikt in typescript waarvoor iemand anders (handmatig) typings voor geschreven heeft dan wil dat nog weleens mis gaan. Zeker voor kleinere projecten is dat best wel een ding. Maar goed, ik denk dat iedere beetje frontend developer toch al heel kritisch is op wat er allemaal voor rommel op npm word gepubliceerd.F.West98 schreef op maandag 22 april 2024 @ 03:16:
Misschien ligt het aan mij, maar ik heb in TS land vaak dat er dan toch at runtime ineens allerlei zaken niet meer zo type safe blijken als ze in de code lijken. Misschien related aan dat Vite verhaal (wist ik niet, goed om te weten), maar toch ook soms third party libraries die in hun type bindings Foo beloven en dan at runtime toch stiekem een Bar geven waarna alles omvalt. Dat zijn toch zaken die je in meer "traditioneel" typed languages eigenlijk zelden tegenkomt.
Dus ik beschouw TS nu meer als een soort veredelde JS linter die net even iets meer type safety geeft (vooral binnen je eigen code), maar het voordeel zit m voor mij in de fijnere syntax en features als generics enzo.
Een Stack is geen Vector net zo min [...].
(Dit was wat gehaast getypt terwijl ik twee dingen tegelijkertijd aan het doen was...

Bij nader inzien wordt in het geval van Java's Stack strict genomen LSP niet geschonden: overal waar om een Vector gevraagd wordt kun je ook een Stack aanleveren. Het is alleen conceptueel gezien niet zo zuiver.
Typesafety.Caelorum schreef op maandag 22 april 2024 @ 09:05:
Ik snap ook niet wat het probleem is met C# en covariancy van de arrays.
1
2
3
4
5
6
| Apple[] apples = new Apple[10]; Fruit[] fruits = apples; // Niet geheel typesafe class Fruit { } class Apple : Fruit { } class Banana : Fruit { } |
[ Voor 22% gewijzigd door RayNbow op 22-04-2024 10:33 ]
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
RayNbow schreef op maandag 22 april 2024 @ 09:19:
[...]
Een Stack is geen Vector net zo min een rechthoek een vierkant is.
[...]
Typesafety.
C#:
1 2 3 4 5 6 Apple[] apples = new Apple[10]; Fruit[] fruits = apples; // Niet geheel typesafe class Fruit { } class Apple : Fruit { } class Banana : Fruit { }
1
| fruits[0] = new Banana(); // of new Fruit() for that matter |
Je mag jezelf van de compiler in de voet schieten, maar de runtime voorkomt dat at runtime.System.ArrayTypeMismatchException: Attempted to access an element as a type incompatible with the array.
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Het hele idee van typesafety is wel een beetje dat het compile time wordt afgedwongen.CodeCaster schreef op maandag 22 april 2024 @ 09:24:
[...]
C#:
1 fruits[0] = new Banana(); // of new Fruit() for that matter
[...]
Je mag jezelf van de compiler in de voet schieten, maar de runtime voorkomt dat at runtime.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het is allemaal de schuld van de Rabobank JavaMugwump schreef op maandag 22 april 2024 @ 09:26:
[...]
Het hele idee van typesafety is wel een beetje dat het compile time wordt afgedwongen.
https://ericlippert.com/2...-part-2-array-covariance/Unfortunately, this particular kind of covariance is broken. It was added to the CLR because Java requires it and the CLR designers wanted to be able to support Java-like languages. We then up and added it to C# because it was in the CLR. This decision was quite controversial at the time and I am not very happy about it, but there’s nothing we can do about it now.
Static analysis FTW; ReSharper waarschuwt ervoor.
[ Voor 8% gewijzigd door CodeCaster op 22-04-2024 09:32 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Je bedoelt dat MS Java schaamteloos heeft gekopieerd inclusief features waarvan je de wenselijkheid kunt betwisten.CodeCaster schreef op maandag 22 april 2024 @ 09:29:
[...]
Het is allemaal de schuld van de Rabobank Java
[...]
Static analysis FTW; ReSharper waarschuwt ervoor.
(Al vind ik als hoofdzakelijk Java-dev C# gewoon een betere taal in veel opzichten)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
C# is qua taal ook wat Java had moeten zijn. Het probleem van .NET (en dus C#) was dat het in het begin enorm gekoppeld was aan Microsoft/Windows. Nu zijn ze een andere weg ingeslagen, hebben het multi-platform gemaakt, en proberen het aan te prijzen, etc. etc. Maar als ze dat van begin af aan gedaan hadden, was het markt aandeel van Java een heel stuk kleiner geweest.Mugwump schreef op maandag 22 april 2024 @ 09:32:
[...]
*knip*
(Al vind ik als hoofdzakelijk Java-dev C# gewoon een betere taal in veel opzichten)
Oh, je bedoelt dat het slecht geimplementeerd is. Ik dacht dat je liever had dat het ook contravariant was geweest oid.
:fill(white):strip_exif()/f/image/EEv9fZvZc4nXdVNAWc0XwQxE.png?f=user_large)
Elke nieuwe tab weer die banner.
Ik heb de Windows Update-integratie aan staan, maar:
Op al m'n machines elke keer die banner, dan update ik wel weer handmatig...When a new version of PowerShell is released, it can take up to two weeks for that version to become available through Microsoft Update. Updates are delivered as optional software updates, even if the update contains a security fix.
https://github.com/PowerShell/PowerShell/issues/20474
[ Voor 3% gewijzigd door CodeCaster op 22-04-2024 10:04 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
dus bijv.
pwsh.exe -noexit -nologo
[ Voor 26% gewijzigd door Caelorum op 22-04-2024 10:12 ]

[ Voor 14% gewijzigd door CodeCaster op 22-04-2024 10:14 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Even voor mijn eigen interpretatie: betekent die strikethrough dat je je originele stelling intrekt?RayNbow schreef op maandag 22 april 2024 @ 09:19:
[...]
Een Stack is geen Vector net zo min een rechthoek een vierkant is.
(Dit was wat gehaast getypt terwijl ik twee dingen tegelijkertijd aan het doen was...)
Wat betreft covariant arrays, strict correct is het natuurlijk niet, maar je moet bedenken dat die dingen zijn toegevoegd op het moment dat generics nog geen ding waren. Zonder covariant arrays kun je nooit generieke algoritmes zoals een sort of shuffle op arrays implementeren. Covariance is prima zolang je nooit nieuwe elementen toevoegt. Schrijven is op zich prima zolang de elementen die je schrijft uit de array komen, wat die algoritmes dus typisch doen. Het is lastig om deze eigenschappen af te dwingen in een taal, dus ik snap de keuze wel om ze dan maar covariant te maken en writes te onderwerpen aan een runtime check.
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.
Dat was ook het enige waar ik aan kon denken toen je je stelling maakte, maar dan kun je hooguit stellen dat de naam Stack niet juist gekozen is. Ik vind het wat vergezocht. Het is geen stricte conditie dat het ding LIFO is. Door het af te leiden van een Vector geef je expliciet lees- en schrijf-toegang tot de gehele container.RayNbow schreef op maandag 22 april 2024 @ 09:19:
Bij nader inzien wordt in het geval van Java's Stack strict genomen LSP niet geschonden: overal waar om een Vector gevraagd wordt kun je ook een Stack aanleveren. Het is alleen conceptueel gezien niet zo zuiver.
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.
De Stack-class in Java is ook defacto deprecated. Er wordt (officieel) aangeraden om een Deque te gebruiken als LIFO stack..oisyn schreef op maandag 22 april 2024 @ 10:39:
^^ Ah ik zie zojuist je edit
[...]
Dat was ook het enige waar ik aan kon denken toen je je stelling maakte, maar dan kun je hooguit stellen dat de naam Stack niet juist gekozen is. Ik vind het wat vergezocht. Het is geen stricte conditie dat het ding LIFO is. Door het af te leiden van een Vector geef je expliciet lees- en schrijf-toegang tot de gehele container.
Ik zeg, hoog tijd voor een breaking change..oisyn schreef op maandag 22 april 2024 @ 10:33:
Wat betreft covariant arrays, strict correct is het natuurlijk niet, maar je moet bedenken dat die dingen zijn toegevoegd op het moment dat generics nog geen ding waren.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ja maar dan kom je weer op het punt dat Java geen monomorphization heeft. Dus zelfs mét generics kun je nog steeds niet generieke algoritmes op arrays implementeren als T[] geen subtype is van Object[]
[ Voor 3% gewijzigd door .oisyn op 22-04-2024 11:08 ]
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.
ThomasG schreef op maandag 22 april 2024 @ 10:45:
[...]
De Stack-class in Java is ook defacto deprecated. Er wordt (officieel) aangeraden om een Deque te gebruiken als LIFO stack.
Questionable...This class is likely to be faster than Stack when used as a stack
.edit: ah de overhead zit 'm vast in removeElementAt() gebuikt door pop()
[ Voor 8% gewijzigd door .oisyn op 22-04-2024 11:28 ]
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 zat zelf niet aan Java te denken, maar als we voor breaking changes pleiten, dan kunnen we toch types als (? extends Object)[] introduceren, waar iets als T[] onderhangt?.oisyn schreef op maandag 22 april 2024 @ 10:56:
[...]
Ja maar dan kom je weer op het punt dat Java geen monomorphization heeft. Dus zelfs mét generics kun je nog steeds niet generieke algoritmes op arrays implementeren als een T[] geen subtype is van Object[]
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Dan moet de JVM toch alsnog de array als covariant behandelen? Wat ik zeg, er is geen monomorphization, Java generics zijn niets meer dan syntactische suiker die niet bestaan op VM niveau (dat was iig ooit zo, kan zijn dat dat inmiddels anders is). Als arrays invariant zijn, dan is er geen enkele generieke array-type die een generieke functie kan gebruiken om zijn operaties op te doen.RayNbow schreef op maandag 22 april 2024 @ 11:17:
[...]
Ik zat zelf niet aan Java te denken, maar als we voor breaking changes pleiten, dan kunnen we toch types als (? extends Object)[] introduceren, waar iets als T[] onderhangt?
Wat evt kan is de array te zien als een opaque Object en VM API functies gebruiken voor reads en writes.
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.
1
2
| IList<string> myArray = new string[0]; myArray.Add("foo"); |
Maar dat is op zich toch niet zo'n probleem? De JVM kan toch in eerste instantie onveranderd blijven terwijl je verschillende variances toevoegt aan arrays op taalniveau?.oisyn schreef op maandag 22 april 2024 @ 11:22:
[...]
Dan moet de JVM toch alsnog de array als covariant behandelen?
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ah op die ? extends Fiets! Dat kan idd.RayNbow schreef op maandag 22 april 2024 @ 11:54:
[...]
Maar dat is op zich toch niet zo'n probleem? De JVM kan toch in eerste instantie onveranderd blijven terwijl je verschillende variances toevoegt aan arrays op taalniveau?
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.
Onder andere dat. Het grootste probleem is dat de Vector-class thread-safe is, omdat ze tijdens JDK1.0 dachten dat thread-safe altijd handig zou zijn. Dus zijn vrijwel alle (publieke) methodes in de Vector-class synchronized, en dus altijd langzamer dan een eenzelfde non-synchronized implementatie..oisyn schreef op maandag 22 april 2024 @ 11:11:
[...]
[...]
Questionable...
.edit: ah de overhead zit 'm vast in removeElementAt() gebuikt door pop()
Oh damn, dat wist ik niet eensThomasG schreef op maandag 22 april 2024 @ 13:08:
[...]
Onder andere dat. Het grootste probleem is dat de Vector-class thread-safe is, omdat ze tijdens JDK1.0 dachten dat thread-safe altijd handig zou zijn. Dus zijn vrijwel alle (publieke) methodes in de Vector-class synchronized

[ Voor 8% gewijzigd door .oisyn op 22-04-2024 13:43 ]
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.
On a sidenote, ik heb laatst voor de lol eens COBOL geprobeerd. Dat is ook wel weer uniek om eens gedaan te hebben.
Engineering is like Tetris. Succes disappears and errors accumulate.
Mijn ervaring met frontenders is juist dat er voor elk wissewasje een package wordt geïnstalleerd.RagingPenguin schreef op maandag 22 april 2024 @ 09:17:
[...]
Ja, als je een javascript library gebruikt in typescript waarvoor iemand anders (handmatig) typings voor geschreven heeft dan wil dat nog weleens mis gaan. Zeker voor kleinere projecten is dat best wel een ding. Maar goed, ik denk dat iedere beetje frontend developer toch al heel kritisch is op wat er allemaal voor rommel op npm word gepubliceerd.
Engineering is like Tetris. Succes disappears and errors accumulate.
YouTube: Interview with Senior JS Developer 2024 [NEW]armageddon_2k1 schreef op donderdag 25 april 2024 @ 20:57:
[...]
Mijn ervaring met frontenders is juist dat er voor elk wissewasje een package wordt geïnstalleerd.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld




Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$



Zo, dat moest ik even kwijt
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.
Jij laat er aan het einde niet even een PDFje van bakken voor in de offline administtatie en dus voor het volgende jaar ?.oisyn schreef op dinsdag 30 april 2024 @ 22:15:
Zo, op de valreep maar weer mijn belastingaangifte gedaan.
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld. Nou is mijn hypotheek wat meer werk, met 4 aparte lengingdelen, waarvan een aflossingsvrij leningdeel maar voor een deel aftrekbaar is. MAAR ALS IK VORIG JAAR ALLES AL HEB GEBRUIKT VOOR MIJN WONING, DAN IS DAT DIT JAAR NIET INEENS ANDERS
![]()
![]()
Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$![]()
![]()
![]()
Zo, dat moest ik even kwijt
Jawel, die heb ik daarna ook geopend, maar het formulierscherm is fijner omdat die gewoon kwa layout overeenkomt. In die PDF zit je toch meer te zoeken. Maar dat alles maakt mijn rant niet minder valide, en dat was wat het is, een rant, geen vraag om een oplossinggekkie schreef op dinsdag 30 april 2024 @ 22:24:
[...]
Jij laat er aan het einde niet even een PDFje van bakken voor in de offline administtatie en dus voor het volgende jaar ?
Ik moet mijn VT over 2024 ook aanpassen vanwege wat veranderingen. Denk maar niet dat je gewoon je vorige ingevulde formulier krijgt zodat je direct aanpsasingen kan maken. Nee, ze vullen dat hele ding opnieuw in op basis van oude gegevens. Kun je dus wéér al die vragen gaan zitten beantwoorden

[ Voor 35% gewijzigd door .oisyn op 30-04-2024 22:30 ]
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.
Huh... Ik heb die van mij rond 21:31 afgerond. Ben blijkbaar niet de enige die er net zo mee omgaat als middelbare school huiswerk..oisyn schreef op dinsdag 30 april 2024 @ 22:15:
Zo, op de valreep maar weer mijn belastingaangifte gedaan.
Yup, exact dezelfde situatie voor mij. Inclusief krachttermen. En dan te bedenken dat er andere landen zijn waar het nog erger is..oisyn schreef op dinsdag 30 april 2024 @ 22:15:
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld. Nou is mijn hypotheek wat meer werk, met 4 aparte lengingdelen, waarvan een aflossingsvrij leningdeel maar voor een deel aftrekbaar is. MAAR ALS IK VORIG JAAR ALLES AL HEB GEBRUIKT VOOR MIJN WONING, DAN IS DAT DIT JAAR NIET INEENS ANDERS
![]()
![]()
Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$![]()
![]()
![]()
Zo, dat moest ik even kwijt

"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Haha thanks voor de reminder!! Nog net ook op de valreep kunnen indienen…..oisyn schreef op dinsdag 30 april 2024 @ 22:15:
Zo, op de valreep maar weer mijn belastingaangifte gedaan.
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld. Nou is mijn hypotheek wat meer werk, met 4 aparte lengingdelen, waarvan een aflossingsvrij leningdeel maar voor een deel aftrekbaar is. MAAR ALS IK VORIG JAAR ALLES AL HEB GEBRUIKT VOOR MIJN WONING, DAN IS DAT DIT JAAR NIET INEENS ANDERS
![]()
![]()
Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$![]()
![]()
![]()
Zo, dat moest ik even kwijt
Moet zeggen dat het in mijn geval niet eens zo heel rampzalig is. Eigenlijk is alles behalve de VvE-reserves vooringevuld (dat was dan wel ff zoeken, want dat moet weer met een 'fictieve bankrekening').
En ja, je moet allerlei stomme next-next-finish checkvraagjes doen, maar ergens is dat denk ik ook wel weer een beetje een vorm van juridisch af- / indekken. Belastigingstelsels zijn voor de gemiddelde sterveling vaak zo complex dat je makkelijk iets over het hoofd ziet wat je bij een controle aardig in de problemen kan brengen. Het zou wel helpen als de eerste vraag was 'is er ten opzichte van vorig jaar iets veranderd omtrent uw hypotheek?' oid.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Hmja, maar er zijn ook nog zaken als belasting voordeel hier en daar, die er afgelopen jaar niet waren... Daar zit hem dan die extra 1000,- euro in, ga ik dan maar van uit.Toren schreef op woensdag 1 mei 2024 @ 08:24:
Ik vind het een beetje black magic hoor die belastingaangifte iedere keer. Veranderd niets in mijn situatie, toch krijg ik ineens 1000 euro meer terug. Back, back, check, check, ja toch echt de goede gegevens. En vorig jaar ook. Indienen en cashen dan maar en hopen dat er niet een slimme inspecteur is die me keihard een draai om de oren geeft omdat ik onbedoeld toch iets fout heb gedaan

Hay 365 dias en un año y 366 occasiones para festejar (Boliviaans spreekwoord)
Als je die eenmaal een voorlopige aanslag krijgt, kom je er nooit meer vanaf volgens mij. En ieder jaar is het hetzelfde liedje. Ze krijgt een voorlopige aanslag waarin staat dat ze alvast vooruit moet betalen en als de daadwerkelijke aangifte ingevuld is, krijgen we dat geld net zo hard weer terug. En dat is dan niet omdat we de aangifte gezamenlijk doen en dan dingen met elkaar weg kunnen strepen, maar gewoon omdat die voorlopige aangifte helemaal niet nodig is.
Je zou dan verwachten dat er na een paar jaar een lichtje gaat branden, maar nee.
Je kunt natuurlijk je voorlopige aanslag ook aanpassen zodat je niet meer hoeft te betalendev10 schreef op woensdag 1 mei 2024 @ 08:43:
Voor mijn vrouw heeft de belastingdienst een paar jaar geleden bedacht dat het echt nodig is dat zij een voorlopige aanslag krijgt. In dat specifieke jaar was dat geen hele gekke gedachte, maar dat was eenmalig en is nu echt niet meer nodig.
Als je die eenmaal een voorlopige aanslag krijgt, kom je er nooit meer vanaf volgens mij. En ieder jaar is het hetzelfde liedje. Ze krijgt een voorlopige aanslag waarin staat dat ze alvast vooruit moet betalen en als de daadwerkelijke aangifte ingevuld is, krijgen we dat geld net zo hard weer terug. En dat is dan niet omdat we de aangifte gezamenlijk doen en dan dingen met elkaar weg kunnen strepen, maar gewoon omdat die voorlopige aangifte helemaal niet nodig is.
Je zou dan verwachten dat er na een paar jaar een lichtje gaat branden, maar nee.
Maar ben het met je eens, de belastingdienst is alleen proactief als zij iets van jou willen, niet andersom.
Dat kun je rustig vergeten haha doen ze echt niet.dev10 schreef op woensdag 1 mei 2024 @ 08:43:
Je zou dan verwachten dat er na een paar jaar een lichtje gaat branden, maar nee.
Ik heb dat 10 jaar terug ook gehad en toen gebeld met ze en toen adviseerden ze me om het zo in te vullen voor de voorlopige aanslag dat het totaal niet klopte met de werkelijkheid maar dat de conclusie was dat er geen voorlopige aanslag meer nodig was. Dus liegen op mijn aangifte vroeg ik nog? Ja dat was het advies van de belastingdienst dus.
Werkte uiteindleijk wel en werd met de jaarlijkse aangifte vanzelf weer rechtgetrokken.
Dus mocht je ook de haren uit je kop hebben getrokken omdat de boel niet meer werkt. Heb geduld. Hulp is onderweg.
Een voorlopige aangifte is natuurlijk wat anders dan de definitieve aangifte. Bij een VT kun je een schatting invullen zodat dat in de loop van dat jaar al verrekend kan worden. Het is geen fraude oid om daar niet "de waarheid" te vertellen, om het simpele feit dat de waarheid nog niet vaststaat. De verrekening komt met de definitieve aanslag.Toren schreef op woensdag 1 mei 2024 @ 09:49:
[...]
Dat kun je rustig vergeten haha doen ze echt niet.
Ik heb dat 10 jaar terug ook gehad en toen gebeld met ze en toen adviseerden ze me om het zo in te vullen voor de voorlopige aanslag dat het totaal niet klopte met de werkelijkheid maar dat de conclusie was dat er geen voorlopige aanslag meer nodig was. Dus liegen op mijn aangifte vroeg ik nog? Ja dat was het advies van de belastingdienst dus.
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.
Je zegt het daar zelf: "bewust foute dingen". Maar een schatting is nooit fout. Een schatting kan alleen achteraf juist zijn.Toren schreef op woensdag 1 mei 2024 @ 13:00:
Nee het is geen fraude maar het voelde toch wel raar om bewust foute dingen in te vullen terwijl diezelfde toko je keihard aanpakt bij een cent meer of minder bij je kinderopvangtoeslag.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Zooooo herkenbaar..oisyn schreef op dinsdag 30 april 2024 @ 22:15:
Zo, op de valreep maar weer mijn belastingaangifte gedaan.
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld. Nou is mijn hypotheek wat meer werk, met 4 aparte lengingdelen, waarvan een aflossingsvrij leningdeel maar voor een deel aftrekbaar is. MAAR ALS IK VORIG JAAR ALLES AL HEB GEBRUIKT VOOR MIJN WONING, DAN IS DAT DIT JAAR NIET INEENS ANDERS
![]()
![]()
Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$![]()
![]()
![]()
Zo, dat moest ik even kwijt
Elk jaar zie ik ook weer dat de leningdelen dezelfde naam hebben (dat zal de bank wel zo doorgeven). Maar daardoor moet ik gegevens aanvullen voordat ik uberhaubt weet welk leningdeel het is.
De bankrekeningen bij ING leveren ook pareltjes op in de aangifte. Elk virtueel spaarpotje levert een eigen rekening op met een willekeurige code zonder omschrijving of iban. Dat levert dus 24 geanonimiseerde rekeningen op....grrr.
Maar als je denkt dat het niet slechter kan, wacht dan totdat er een dierbare overlijdt en je de aangifte op papier mag gaan invullen.
When life gives you lemons, start a battery factory
Hier in België is het simpeler, daar staat alles al ingevuld.oisyn schreef op dinsdag 30 april 2024 @ 22:15:
Zo, op de valreep maar weer mijn belastingaangifte gedaan.
MAAR WAAROM MOET IK ELK FUCKING JAAR WEER OPNIEUW DAT HELE RIEDELTJE MET MIJN HYPOTHEEK DOEN?!?!
Heeft u het gehele bedrag gebruikt voor uw woning? Wanneer heeft u uw hypotheek afgesloten? Was deze volledig aftrekbaar? Etc, etc. Echt, onthou gewoon wat ik de laatste 3 jaar al heb ingevuld. Nou is mijn hypotheek wat meer werk, met 4 aparte lengingdelen, waarvan een aflossingsvrij leningdeel maar voor een deel aftrekbaar is. MAAR ALS IK VORIG JAAR ALLES AL HEB GEBRUIKT VOOR MIJN WONING, DAN IS DAT DIT JAAR NIET INEENS ANDERS
![]()
![]()
Oh, maar weet je, dan open ik die van 2022 gewoon ernaast, zodat ik alles gewoon direct kan overnemen. OH, WILT U MEERDERE TABS OPENEN? DAT SNAPPEN WIJ NIET! U BENT NU UITGELOGD BIJ DIGID.
Fuuuuuu #%@#^&#&$%@$%@#$![]()
![]()
![]()
Zo, dat moest ik even kwijt


Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag
Dat is (zeker dit jaar) redelijk normaal, aangezien veel toeslagen & belastingschijven zijn veranderd t.o.v. "vroeger"Toren schreef op woensdag 1 mei 2024 @ 08:24:
Ik vind het een beetje black magic hoor die belastingaangifte iedere keer. Veranderd niets in mijn situatie, toch krijg ik ineens 1000 euro meer terug. Back, back, check, check, ja toch echt de goede gegevens. En vorig jaar ook. Indienen en cashen dan maar en hopen dat er niet een slimme inspecteur is die me keihard een draai om de oren geeft omdat ik onbedoeld toch iets fout heb gedaan
Maar idd, ik heb vooraf al de PDF van jaar eerder klaar staan en de ctrl-c/ctrl-v even goed geolied.
{signature}
Zo doe ik het ook inderdaad, maar intuïtief voelt het niet juist.Voutloos schreef op woensdag 1 mei 2024 @ 15:01:
Dat van de hypotheekdetails invullen kan ik me helemaal in vinden. Helpt ook niet dat na paar keer wat oude voordelige deals meenemen het lijstje er niet korter op wordt.
Maar idd, ik heb vooraf al de PDF van jaar eerder klaar staan en de ctrl-c/ctrl-v even goed geolied.
Heb daarnaast nog twee hypotheken van/bij mijn ouders. Dat is nooit ingevuld en vereist echt super veel boilerplate.
[ Voor 11% gewijzigd door Matis op 01-05-2024 15:19 ]
If money talks then I'm a mime
If time is money then I'm out of time
Zo gaat het in heel veel gevallen in Nederland ook hoor.Damic schreef op woensdag 1 mei 2024 @ 14:20:
[...]
Hier in België is het simpeler, daar staat alles al ingevuld![]()
gewoon even controleren en voor de rest niets doen meestal wachten op het geld
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Gelukkig binnenkort een weekje vakantie. Ben er wel aan toe.
Werk laptop was gecrasht, dus data kwijt en deze opnieuw moeten inregelen. En gisteren had ik een uitgebreide Confluence pagina gemaakt, om een uurtje later te ontdekken dat hele project was verhuist en de oude (waar ik mijn aanpassing op gedaan had) zojuist was verwijderd.

Prima dat je een project verhuist, maar neem wel de laatste data mee en laat de oude niet 2 weken muteerbaar bestaan én communiceer duidelijk wanneer een project overgaat.
[/rant]
let the past be the past.
Ah, in mijn vakantie. Is het mooi mijn probleem nietxFeverr schreef op woensdag 1 mei 2024 @ 11:07:
Heel de ochtend al bezig om onze Azure DevOps pipelines weer terug op de rails te krijgen, omdat de pipelines het opeens vertikken om bij Azure in te loggen. Blijkt dat het niet aan ons ligt. Inmiddels hebben ze de statuspagina van Azure DevOps bijgewerkt naar 'degraded'.
Dus mocht je ook de haren uit je kop hebben getrokken omdat de boel niet meer werkt. Heb geduld. Hulp is onderweg.
Het is inmiddels ook opgelost, dus je kunt weer terug komen van vakantieCaelorum schreef op woensdag 1 mei 2024 @ 17:38:
[...]
Ah, in mijn vakantie. Is het mooi mijn probleem niet
Ah zuurxFeverr schreef op woensdag 1 mei 2024 @ 11:07:
Heel de ochtend al bezig om onze Azure DevOps pipelines weer terug op de rails te krijgen, omdat de pipelines het opeens vertikken om bij Azure in te loggen. Blijkt dat het niet aan ons ligt. Inmiddels hebben ze de statuspagina van Azure DevOps bijgewerkt naar 'degraded'.
Dus mocht je ook de haren uit je kop hebben getrokken omdat de boel niet meer werkt. Heb geduld. Hulp is onderweg.
Ergens is het idee dat ik met Rust ook dingen zou kunnen die C# niet kan, maar tenzij ik mij ga bemoeien met open source projecten (dan kan ik eigenlijk beter mijn C/C++ skills refreshen), heb ik er eigenlijk geen toepassing voor.
Wat C# betreft, speel ik ook met native AOT en lees ik over source generators (idee is dat je reflection at runtime vervangt door source generators at compile time, zodat je ahead of time kunt compileren). Al met al vind ik het leuk om dingen efficiënter te maken. But I'm conflicted. Het is vooral omdat het mij leuk lijkt, niet omdat ik het ergens nodig voor heb.
Tot zover de random thought of the day.
Kortom, ik twijfel of ik iets aan Rust heb, of dat ik beter dieper in de laatste C# ontwikkelingen kan duiken om daar het onderste uit de kan te halen. Omdat het kan, niet omdat het moet
Zie ook deze blogpost van Marc Gravell (programmeur van Dapper):
https://blog.marcgravell....on-heavy-c-libraries.html
Tegelijkertijd vraag ik mij af of ik blij word van zoveel "magic". Het doet mij denken aan aspect oriented programming, waarbij je met een paar attributes behaviour toevoegt die je verder niet ziet.
Ondanks dat een taal als Go bijvoorbeeld wel erg basic is, is het ook wel weer fijn dat je ziet wat er gebeurt. Er is weinig magic. Of zoals developers zeggen in de eeuwenoude discussies tussen C en C++ ... C++ blijft features toevoegen, totdat niemand meer begrijpt wat de code doet. In C schrijf je gewoon meer code. Maar ja, is dat erg?
Anyways... brain farts. Het is meivakantie en mijn hersenen moeten nog uit

Ask yourself if you are happy and then you cease to be.
Ik loop ook altijd tegen het probleem aan dat ik niet direct iets weet om te bouwen namelijk.
Wat betreft je source generators gedachte-experiment. Dat is iets wat ze in Kotlin nu al erg veel doen middels compiler-plugins. De serialization library is een compiler plugin en dus kom je er compile-time achter of serializers werken of niet. Daarnaast is er een legio andere libraries dat ook op de nieuwe Kotlin K2 compiler architectuur inhaakt middels plugins en dus compile-time source genereert.
Grote nadeel vind ik wel dat libraries dan heel erg vast gaan hangen aan expliciete language-versions. En ik weet niet of ik het daar helemaal mee eens ben.
Op een iets ander niveau gebruik ik nu juist code-generators als een simpele build stap in een project. We hebben een web-app met een lading assets en ik genereer tijdens de build-stap een berg Kotlin files (middels een mooie codegen lib) waardoor ik vervolgens een lading objects heb die de asset-berg representeren inclusief een hoop voorgegenereerde data erin:
- hashes voor versioning
- JS files zijn geparsed en hun dependencies naar andere assets zijn geresolved
- er zijn thumbnails gegenereert voor images
Deze implementeren allemaal een `Asset` interface en vervolgens kunnen we type-safe allemaal dingen met die assets doen, zoals bijvoorbeeld Import Maps genereren voor de frontend.
Codegen, danwel als een script voor compile, of tijdens compilation, zijn best leuke tools. Reflection ben ik absoluut geen fan van omdat je dan vaak de problemen naar runtime verplaatst.
Engineering is like Tetris. Succes disappears and errors accumulate.
Wij gebruiken al langer stukjes codegen (Arrow optics, Protobuf), maar nav het bericht hierboven ben ik me vanmiddag eens wat verder in die codegen gaan verdiepen en heb ik al wel een paar interessante usecases/libraries langs zien komen. Helaas zitten we binnen ons framework nog wel enigszins vast aan oldfashioned reflection dingen (Jakarta, etc), dus niet alle hippe en interessante tools zijn goed toe te passen helaas.
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Codecrafters is op zich een leuk idee, maar 40$ per maand vragen is er echt over imo.armageddon_2k1 schreef op zaterdag 4 mei 2024 @ 10:21:
dan is Codecrafters wel erg leuk.
Het probleem wat je geheid gaat krijgen is dat libraries op een gegeven moment niet meer ondersteund worden, je project niet meer compiled op nieuwe language versies, en niemand (meer) iets begrijpt van je overcomplexe setup. Het web wereldje heeft ook een tijd gehad waarin Babel plugins voor codegen helemaal hip waren, tot dat iedereen op de harde manier leerde dat dat een slecht idee is. Codegen hou ik liever los van de taal, dat maakt het een stuk makkelijker om een van de twee uptegraden of te vervangen met iets anders.armageddon_2k1 schreef op zaterdag 4 mei 2024 @ 10:21:
Grote nadeel vind ik wel dat libraries dan heel erg vast gaan hangen aan expliciete language-versions. En ik weet niet of ik het daar helemaal mee eens ben.
Welke problemen heb je op runtime met reflectie? Behalve dat reflectie op de JVM gewoon slecht is, o.a. door type erasure.Op een iets ander niveau gebruik ik nu juist code-generators als een simpele build stap in een project. We hebben een web-app met een lading assets en ik genereer tijdens de build-stap een berg Kotlin files (middels een mooie codegen lib) waardoor ik vervolgens een lading objects heb die de asset-berg representeren inclusief een hoop voorgegenereerde data erin:
- hashes voor versioning
- JS files zijn geparsed en hun dependencies naar andere assets zijn geresolved
- er zijn thumbnails gegenereert voor images
Deze implementeren allemaal een `Asset` interface en vervolgens kunnen we type-safe allemaal dingen met die assets doen, zoals bijvoorbeeld Import Maps genereren voor de frontend.
Codegen, danwel als een script voor compile, of tijdens compilation, zijn best leuke tools. Reflection ben ik absoluut geen fan van omdat je dan vaak de problemen naar runtime verplaatst.
Alleen al het feit dat je buiten je/het MS/.NET ecosysteem bezig bent is ongelooflijk leerzaam. Het maakt ook dat je weer wat kritischer kunt kijken naar wat je eigenlijk dagelijks aan het doen bent.Lethalis schreef op vrijdag 3 mei 2024 @ 18:02:
Als je een boek over Rust aan het lezen bent, maar er eigenlijk geen toepassing voor hebt omdat je alles al kan met C# dat je nodig hebt.
Gewoon doen.
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.
Klopt maar ik doe hier de free opdrachtenGhehe schreef op zondag 5 mei 2024 @ 16:56:
[...]
Codecrafters is op zich een leuk idee, maar 40$ per maand vragen is er echt over imo.
Engineering is like Tetris. Succes disappears and errors accumulate.
We moeten hier even onderscheid maken tussen compile-time codegen en build-time codegen. Is dat anders? In Kotlin iig, wel. Build-time is wanneer de gradle build task aangeroepen wordt en compile-time is wanneer de compiler echt draait n.a.v. de build step.RagingPenguin schreef op zondag 5 mei 2024 @ 20:11:
[...]
Het probleem wat je geheid gaat krijgen is dat libraries op een gegeven moment niet meer ondersteund worden, je project niet meer compiled op nieuwe language versies, en niemand (meer) iets begrijpt van je overcomplexe setup. Het web wereldje heeft ook een tijd gehad waarin Babel plugins voor codegen helemaal hip waren, tot dat iedereen op de harde manier leerde dat dat een slecht idee is. Codegen hou ik liever los van de taal, dat maakt het een stuk makkelijker om een van de twee uptegraden of te vervangen met iets anders.
In Gradle kan je taken toevoegen die als dependency draaien van een andere task. Zo heb ik dus een Gradle plugin welke wat tasks toevoegt voordat de compile task echt start.
De compile-time codegen is echt een stuk code dat gebruikt maakt van de compiler hooks en _tijdens_ compileren draait. Daar heb ik nog erg weinig mee gedaan.
Of het overcomplex is durf ik niet goed in te schatten, bij ons is het gewoon een simpel scriptje waar zelf nog breakpoints in te zetten zijn, en welke gewoon de Gradle coding conventions volgt. Anders dan de JS wereld waar absoluut geen enkele conventie bestaat.
Welke problemen heb je op runtime met reflectie? Behalve dat reflectie op de JVM gewoon slecht is, o.a. door type erasure.
Engineering is like Tetris. Succes disappears and errors accumulate.
Ik gebruik een custom Gradle plugin met daarin KotlinPoet. Dat werkt goed. Maar het is ook voor iets heel simpels he? Een object hierarchy die onze resources beschrijven.F.West98 schreef op zondag 5 mei 2024 @ 04:20:
@armageddon_2k1 Welke library/ies gebruik je hiervoor? Zijn dat K2-specifieke zaken? En hoe ingewikkeld was het om zoiets te implementeren en in je projecten te integreren?
Wij gebruiken al langer stukjes codegen (Arrow optics, Protobuf), maar nav het bericht hierboven ben ik me vanmiddag eens wat verder in die codegen gaan verdiepen en heb ik al wel een paar interessante usecases/libraries langs zien komen. Helaas zitten we binnen ons framework nog wel enigszins vast aan oldfashioned reflection dingen (Jakarta, etc), dus niet alle hippe en interessante tools zijn goed toe te passen helaas.
Arrow Optics etc maken gebruik van KSP of de K2 compiler extensions en ik ben daar niet zo'n fan van. Soms denk ik dat het namelijk onnodig is en het grote probleem dat je nu veel ziet is dat al die libraries op hun release-notes nu hebben staan dat een bepaalde releases hard vast zitten aan een specifieke Kotlin minor version. En dat is prima als er 1 library is die dat heeft, maar je ziet nu dat jan en alleman compiler plugins gaan maken.
Wij hebben op werk juist een Kotlin project uitgefaseerd omdat ie bijna niet up te daten was vanwege gedateerde KSP afhankelijkheden.
Engineering is like Tetris. Succes disappears and errors accumulate.
Java of JavaScript?Mugwump schreef op dinsdag 7 mei 2024 @ 10:32:
[Afbeelding]
Nou ben ik doorgaans niet iemand die geweld goed praat, maar hier wil ik het nog wel op verzachtende omstandigheden gooien.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Dat is toch hetzelfde?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.