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.
Verander gewoon naar "nysio.".oisyn schreef op donderdag 25 januari 2024 @ 14:36:
[...]
Dan zijn die restricties gewoon dom
.edit: die regels lijken iig niet in BalusC in "Nickchange regels" te staan?
.edit: ook op de registratiepagina lijkt een nick als de mijne gewoon te werken
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Maar hij beweegt niet meer ( of was dat al een tijdje niet meer zo? ).oisyn schreef op donderdag 25 januari 2024 @ 14:22:
[...]
Mijn avatar is nog steeds hetzelfde poppetje achter een scherm, hij heeft alleen een upgrade gehad
“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.”
Ja dat weet ik dus niet meerWoy schreef op vrijdag 26 januari 2024 @ 09:13:
[...]
Maar hij beweegt niet meer ( of was dat al een tijdje niet meer zo? )

Deze, die ik gecropt en geloopt heb van dat gifje waarbij het poppetje zichzelf helemaal naar de tering mept.
:strip_exif()/u/12461/avatar.gif?f=community)
En deze, die ik zelf getekend heb (maar duidelijk geinspireerd op die andere
/u/12461/avatar%252060x60.png?f=community)
Kan best dat ie al een tijdje op die laatste stond; die gebruikte ik namelijk ook bij andere websites als avatar, en ik zag dat steeds meer mensen die geanimeerde begonnen over te nemen, dus dat vond ik een beetje irritant.
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.
En om mee te gaan met de hype heb ik mijn avatar ook maar een remake gegeven
[ Voor 30% gewijzigd door Woy op 26-01-2024 09:37 ]
“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.”
https://web.archive.org/w...eakers.net/gallery/12461/
@Woy Nice!
[ Voor 4% gewijzigd door .oisyn op 26-01-2024 09:40 ]
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.
Da's niet hip, je moet AI gebruiken.Caelorum schreef op vrijdag 26 januari 2024 @ 10:44:
nah, deze werkt prima
/f/image/iYnFxcElCtRlAdgau4wLB13b.png?f=fotoalbum_large)
Compleet met misplaatste letters en alles.
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.
"random pattern of aligned brown and pink squares"Kriekel schreef op vrijdag 26 januari 2024 @ 10:47:
Ik heb nog geen eens de moeite genomen om de standaard afbeelding aan te passen
/f/image/aYaQS2M9xj5iYMzFsUFqwpaz.png?f=fotoalbum_large)
[ Voor 25% gewijzigd door .oisyn op 26-01-2024 11:00 ]
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.
Bijgewerkt.oisyn schreef op vrijdag 26 januari 2024 @ 10:59:
[...]
"random pattern of aligned brown and pink squares"
[Afbeelding]
pfff prima, als het zo makkelijk wordt gemaakt....oisyn schreef op vrijdag 26 januari 2024 @ 10:57:
[...]
Da's niet hip, je moet AI gebruiken.
[Afbeelding]
Compleet met misplaatste letters en alles.

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.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Ja ik had maar besloten remote te gaan kijken .. en zie daar geen sneeuwstormGhehe schreef op donderdag 1 februari 2024 @ 18:53:
Dit weekend FOSDEMEn voor één keer geven ze slechts "kans op lichte regen"
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.
Maar ook hier mis ik de animatie. Tijd dat dat ook beter beschikbaar wordt qua generatie
“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.”
Ik kreeg hem met een water pistol niet beter dan dit
En bonuspunten voor de derde arm.
[ Voor 4% gewijzigd door Creepy op 02-02-2024 08:15 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Hopelijk ook geen coronastorm achteraf. Ik was het weer even vergeten maar het gaan weer overvolle zalen zijn en een talk te vroeg naar je devroom gaan om plaats te hebbengekkie schreef op donderdag 1 februari 2024 @ 21:33:
[...]
Ja ik had maar besloten remote te gaan kijken .. en zie daar geen sneeuwstorm

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Het wordt pas echt leuk als iedereen alle avatars op een hoop gooit en ze vervolgens willekeurig verdeeld worden.Janoz schreef op vrijdag 2 februari 2024 @ 14:00:
Jammer dat iedereen zijn avatar ook aangepast heeft. Ik weet het van sommige nog wel, maar daadwerkelijk de voor en na zien is nu wat lastiger

"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
Je had erbij moeten zijnJanoz schreef op vrijdag 2 februari 2024 @ 14:00:
Jammer dat iedereen zijn avatar ook aangepast heeft. Ik weet het van sommige nog wel, maar daadwerkelijk de voor en na zien is nu wat lastiger
Nou vooruit dan maar, omdat je het zo lief vraag en omdat .oisyn er zo ontzettend veel werk in heeft gestoptJanoz schreef op vrijdag 2 februari 2024 @ 14:00:
Jammer dat iedereen zijn avatar ook aangepast heeft. Ik weet het van sommige nog wel, maar daadwerkelijk de voor en na zien is nu wat lastiger
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Naja dit jaar hebben een stelletje boeren als nog voor een boerenshitstorm gezorgdGhehe schreef op vrijdag 2 februari 2024 @ 13:49:
[...]
Hopelijk ook geen coronastorm achteraf. Ik was het weer even vergeten maar het gaan weer overvolle zalen zijn en een talk te vroeg naar je devroom gaan om plaats te hebbenOm het op zijn Hollands te zeggen: "gezellig"
Remote kijken heeft ook het voordeel dat je nog makkelijk kunt switchen als de talk toch tegen blijkt te vallen.

Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag
“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.”
[ Voor 95% gewijzigd door Woy op 04-02-2024 17:59 ]
“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.”
[ Voor 95% gewijzigd door Woy op 04-02-2024 17:59 ]
“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.”
Woy schreef op zondag 4 februari 2024 @ 17:57:
@Damic Ja dat is wel erg dom. Iedereen weet toch dat je beter twee hele grote ifs met een hoop or operators kan maken.
Je if else zit verkeerd


Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag
Ja... lekker voor een dichte deur staan omdat iedereen uit de vorige talk bleef zitten.Ghehe schreef op vrijdag 2 februari 2024 @ 13:49:
[...]
Hopelijk ook geen coronastorm achteraf. Ik was het weer even vergeten maar het gaan weer overvolle zalen zijn en een talk te vroeg naar je devroom gaan om plaats te hebbenOm het op zijn Hollands te zeggen: "gezellig"
Gelukkig niemand zien sniffen, maar het zal wel weer een mooie test zijn voor ons afweer systeem
Er was dit jaar beduidend meer volk op FOSDEM. Elke devroom waar ik langs ben geweest, zat stampensvol. Zelf devrooms waar ik van dacht dat het wel mee zou vallen (Debugger devroom, Perl devroom*), bleken ook capaciteitsproblemen te hebben.Kriekel schreef op maandag 5 februari 2024 @ 10:18:
[...]
Ja... lekker voor een dichte deur staan omdat iedereen uit de vorige talk bleef zitten.
Wel goed was dat ze in het centrale F gebouw bijna alle refters open hebben gedaan, waar dat vorige jaren nog gedeeltelijk was afgesloten. Kon je op je gemak een biertje/koffie/mate drinken aan een tafel
In de Monitoring & Observabilityroom zaten een paar zieke mensen zonder zelfbesef en mondmaskerKriekel schreef op maandag 5 februari 2024 @ 10:18:
[...]
Gelukkig niemand zien sniffen, maar het zal wel weer een mooie test zijn voor ons afweer systeem.

* Dat ik in de Perl room en de debugger room zat, heeft niets met elkaar te maken.
[ Voor 3% gewijzigd door Ghehe op 05-02-2024 12:11 ]
Die is wel erg ernstigmrdemc schreef op vrijdag 19 januari 2024 @ 15:27:
[...]
Die hele omgeving zit vol met vertaalfouten
Deze kwam ik bijv. ook laatst tegen: https://learn.microsoft.c...rsal-print-ready-printers
Met merken als 'Scherpe', 'Broer', 'Triumph-Overwinnen', 'Konica Buitenwereld', 'Konica Terechtkomen', etc.

Een andere mooie taalfout die er vroeger jaren op stond was:
"Hoe weet ik dat ik besmet ben met Microsoft Defender?"

☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
Zit er nog wat ontwikkeling in Perl (neem aan 5.x ipv 6.x / Raku ?)Ghehe schreef op maandag 5 februari 2024 @ 12:10:
* Dat ik in de Perl room en de debugger room zat, heeft niets met elkaar te maken.
Er zijn in de laatste releases wel wat leuke dingen toegevoegd zoals native classes (meer OO features komen in volgende releases), echte booleans, try-catch blocks, defers, ... En het is dan ook leuk om op FOSDEM talks te volgen van de core Perl developers en achteraf een babbeltje te slaangekkie schreef op maandag 5 februari 2024 @ 21:11:
[...]
Zit er nog wat ontwikkeling in Perl (neem aan 5.x ipv 6.x / Raku ?)
© ocf81 1981-infinity
Live the dream! | Politiek Incorrecte Klootzak uitgerust met The Drive to Survive
Bestrijd de plaag die woke heet! | Servitisatie plaveit de weg naar slavernij. Kies je eigen weg!
Pak de hooivorkenocf81 schreef op dinsdag 6 februari 2024 @ 13:31:
XML is mijns inziens geen code, omdat het slechts configuratie aanstuurt. Een developer bij het bedrijf waar ik werk vind echter dat dit wel als een vorm van code moet worden gezien t.a.v. minder technisch begaafde consultants die hier bij zouden kunnen als ze dat echt zouden willen. Wat vinden jullie?
HTML is ook geen code
Rare framing. Wat is het doel? Moet iets code zijn om het af te schermen van de handen van consultants?ocf81 schreef op dinsdag 6 februari 2024 @ 13:31:
XML is mijns inziens geen code, omdat het slechts configuratie aanstuurt. Een developer bij het bedrijf waar ik werk vind echter dat dit wel als een vorm van code moet worden gezien t.a.v. minder technisch begaafde consultants die hier bij zouden kunnen als ze dat echt zouden willen. Wat vinden jullie?
Maar ik vind het geen code, omdat het (uitzonderingen daargelaten) niet uitgevoerd wordt. XSLT daarentegen...
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Daar komt het in de basis wel op neer.CodeCaster schreef op dinsdag 6 februari 2024 @ 13:53:
[...]
Rare framing. Wat is het doel? Moet iets code zijn om het af te schermen van de handen van consultants?
Dat was ook mijn eerste reactie. Maar ik heb zijn vorige functie overgenomen, dus daar zit misschien ook wel wat meer achter. Een vorm van, naar ik aanneem goed bedoelde, aansturing van de achterbank.CodeCaster schreef op dinsdag 6 februari 2024 @ 13:53:
[...]
Maar ik vind het geen code, omdat het (uitzonderingen daargelaten) niet uitgevoerd wordt. XSLT daarentegen...
[ Voor 3% gewijzigd door ocf81 op 06-02-2024 14:39 ]
© ocf81 1981-infinity
Live the dream! | Politiek Incorrecte Klootzak uitgerust met The Drive to Survive
Bestrijd de plaag die woke heet! | Servitisatie plaveit de weg naar slavernij. Kies je eigen weg!
“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.”
Probleem is dat als je de 'delete'-functie aanzet voor MDM-achtige zaken, je serieuze onherstelbare schade kan toebrengen die niet zo 1-2-3 is te herstellen zonder een complete backup terug te zetten en weer opnieuw te beginnen. Ik had zelf zoiets van: "een stevige waarschuwing in de KB zou voldoende moeten zijn, we zijn geen kinderen", maar dat was voor deze collega een brug te ver.Woy schreef op dinsdag 6 februari 2024 @ 14:45:
De vraag of het code is, is niet echt relevant IMHO. De vraag is of het een geschikt formaat is voor de gebruiker die er iets mee moet, dat is ook weer afhankelijk van feedback bij bijvoorbeeld fouten e.d.
© ocf81 1981-infinity
Live the dream! | Politiek Incorrecte Klootzak uitgerust met The Drive to Survive
Bestrijd de plaag die woke heet! | Servitisatie plaveit de weg naar slavernij. Kies je eigen weg!
[ Voor 3% gewijzigd door .oisyn op 06-02-2024 15:15 ]
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.
© ocf81 1981-infinity
Live the dream! | Politiek Incorrecte Klootzak uitgerust met The Drive to Survive
Bestrijd de plaag die woke heet! | Servitisatie plaveit de weg naar slavernij. Kies je eigen weg!
In dit geval natuurlijk een absurd voorbeeld, maar zo heel gek is het niet eens om bijv. het getal om te zetten naar een string, het laatste karakter te pakken, en daar dan 5 ifs voor te doen; ieder getal dat op 0, 2, 4, 6, of 8 eindigt is even, 'else' is odd.
Het alternatief dat je vaak ziet is een modulo operator (i % 2 == 0), maar dat is eigenlijk het verkeerd gebruiken van die syntax en het zou een logische verwachting zijn dat dit langzamer is bij grote getallen.
Alleen voor de gein heb ik het toch maar eens in een scriptje gegooid, en de resultaten zijn redelijk duidelijk. Met 100 runs van 100.000 iterations:
1
2
3
| modEvenOdd: 10000000 it -> 137 ms, 0.00001 ms/it ifModEvenOdd: 10000000 it -> 894 ms, 0.00009 ms/it ifEvenOdd: 10000000 it -> 821 ms, 0.00008 ms/it |
Interessant is dat bij 100 miljoen iterations de modulo niet langzamer wordt, en in sommige gevallen zelfs sneller, en de strings langzamer:
1
2
3
| modEvenOdd: 1000000000 it -> 12217 ms, 0.00001 ms/it ifModEvenOdd: 1000000000 it -> 111577 ms, 0.00011 ms/it ifEvenOdd: 1000000000 it -> 98411 ms, 0.00010 ms/it |
Ergens logisch dat iets omzetten naar een string, daar iets mee doen, en dan het antwoord teruggeven niet sneller is dan direct een berekening doen, maar wel interessant dat op internet veel te vinden is over hoe traag een modulo operator is terwijl het dus eigenlijk wel heel erg meevalt.
[ Voor 3% gewijzigd door ocf81 op 06-02-2024 16:26 ]
© ocf81 1981-infinity
Live the dream! | Politiek Incorrecte Klootzak uitgerust met The Drive to Survive
Bestrijd de plaag die woke heet! | Servitisatie plaveit de weg naar slavernij. Kies je eigen weg!
Waarom is dat niet zo gek?Oon schreef op dinsdag 6 februari 2024 @ 16:08:
[...]
In dit geval natuurlijk een absurd voorbeeld, maar zo heel gek is het niet eens om bijv. het getal om te zetten naar een string, het laatste karakter te pakken, en daar dan 5 ifs voor te doen; ieder getal dat op 0, 2, 4, 6, of 8 eindigt is even, 'else' is odd.
Wat is er verkeerd aan?Het alternatief dat je vaak ziet is een modulo operator (i % 2 == 0), maar dat is eigenlijk het verkeerd gebruiken van die syntax
Wat men dan even vergeet is dat het omzetten van een getal naar een string ook doorgaans de modulo-operator gebruikt, maar dan meerdere keren omdat het eindresultaat meerdere digits bevat.en het zou een logische verwachting zijn dat dit langzamer is bij grote getallen.
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.
Tijd om vaker BCD te gebruiken!.oisyn schreef op dinsdag 6 februari 2024 @ 16:29:
[...]
Wat men dan even vergeet is dat het omzetten van een getal naar een string ook doorgaans de modulo-operator gebruikt, maar dan meerdere keren omdat het eindresultaat meerdere digits bevat.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ja, maar ik denk dat als je een i - Math.floor(i / 10) * 10 doet het ook niet veel sneller zou zijn..ocf81 schreef op dinsdag 6 februari 2024 @ 16:21:
@Oon Dat ligt er toch vooral aan dat strings nog langzamer zijn, want meer data om te verschuiven.
Maar omdat we toch bezig zijn, ook nog even getest:
1
2
3
4
| function ifModMathFloorEvenOdd(num) { let lastDigit = num - Math.floor(num / 10) * 10; return (lastDigit % 2 === 0) ? 1 : 0; } |
En dat gaf toch wel verrassend resultaat:
1
2
3
4
| modEvenOdd: 1000000 it -> 14 ms, 0.00001 ms/it ifModEvenOdd: 1000000 it -> 107 ms, 0.00011 ms/it ifEvenOdd: 1000000 it -> 102 ms, 0.00010 ms/it ifModMathFloorEvenOdd: 1000000 it -> 21 ms, 0.00002 ms/it |
Dus een modulo op alleen het laatste getal mbv delen is ongeveer twee keer zo langzaam als direct een modulo (logisch, want je bent twee keer aan het delen), maar een stuk sneller dan met strings.
Waarom wel?
Ik vind dat oplossingen vaak afgekeurd worden omdat het niet de normale oplossing is, maar als je na de 3e CPU cycle resultaat hebt terwijl een modulo er meer nodig heeft zou dat best wel een prima oplossing zijn toch?
Goeie vraag, ik weet zo even geen usecase voor het meenemen van het restgetal na delen. In dit geval wil je voorkomen dat je moet delen, want getallen delen wordt een keer traag als je getal hoog genoeg is.[...]
Wat is er verkeerd aan?
Hoe kom je aan 3 cycles?Oon schreef op dinsdag 6 februari 2024 @ 16:34:
[...]
Waarom wel?
Ik vind dat oplossingen vaak afgekeurd worden omdat het niet de normale oplossing is, maar als je na de 3e CPU cycle resultaat hebt terwijl een modulo er meer nodig heeft zou dat best wel een prima oplossing zijn toch?
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Maar dan heb je het specifiek over javascript, dat geen expliciet verschil kent tussen integers en floats. Als je het hebt over integers, dan is de floor niet nodig want een deling is al een integer-deling, en deling en modulo gebruikt doorgaans hetzelfde circuit (de operaties zijn namelijk identiek). Dus met een x - (x / 10) * 10 heb je uiteindelijk meer operaties dan alleen x % 10 (namelijk een vermenigvuldiging en een aftrekking)Oon schreef op dinsdag 6 februari 2024 @ 16:34:
[...]
Ja, maar ik denk dat als je een i - Math.floor(i / 10) * 10 doet het ook niet veel sneller zou zijn..
Hoe denk je precies dat een getal wordt omgezet naar een string?Waarom wel?
Ik vind dat oplossingen vaak afgekeurd worden omdat het niet de normale oplossing is, maar als je na de 3e CPU cycle resultaat hebt terwijl een modulo er meer nodig heeft zou dat best wel een prima oplossing zijn toch?
Dat lijkt me een boude stelling. We hebben het over een typische ordegrootte van enkele tientallen cycles zowel best case als worst case, met de worst case iets van 2-3x zo duur als de best case. Het wordt natuurlijk anders als je het niet hebt over types die mappen op hardware registers maar iets als bigints of bignums oid, maar dan ga je ook daar voorbij aan het feit dat het omzetten van zo'n getal naar decimale digits óók veel langzamer is.Goeie vraag, ik weet zo even geen usecase voor het meenemen van het restgetal na delen. In dit geval wil je voorkomen dat je moet delen, want getallen delen wordt een keer traag als je getal hoog genoeg is.
Je gaat pas echt voordeel hebben als je een decimaal datatype gebruikt. Dat is hetzelfde principe als dat bitwise operators sneller zijn dan modulo, die je kunt gebruiken als de modulo een macht van 2 is. In dit geval: x & 1 == 0
Ben even in de Rust source code gedoken. Hier staat de code die een integer omzet in een getal. Je hoeft geen Rust te kennen om te zien dat daar een MOD en een DIV in een loop gebruikt worden. Door de omzetting naar string roep je een operatie aan die veel complexer is dan een MOD en intern gewoon gebruik maakt van MOD. Het kan hoe dan ook dus nooit sneller zijn
[ Voor 18% gewijzigd door .oisyn op 06-02-2024 16:54 ]
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 caveat is hier wel dat de eerste drie waarschijnlijk naar exact dezelfde assembly compileren.
.edit: correct
[ Voor 50% gewijzigd door .oisyn op 06-02-2024 17: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.
XML slechts voor configuratie ?ocf81 schreef op dinsdag 6 februari 2024 @ 13:31:
XML is mijns inziens geen code, omdat het slechts configuratie aanstuurt. Een developer bij het bedrijf waar ik werk vind echter dat dit wel als een vorm van code moet worden gezien t.a.v. minder technisch begaafde consultants die hier bij zouden kunnen als ze dat echt zouden willen. Wat vinden jullie?
* gekkie is nu bang om het SOAPje te laten vallen in de developers douche
Als je na de 3e if een match hebt kun je meteen de rest skippen en een return doen, dat een theoretische winst kunnen opleveren t.o.v. voor ieder getal moeten delen. Dan zou je dus alleen het laatste cijfer van een getal moeten kunnen krijgen zonder alsnog ook te delen.
Interessant, en leuk om te zien dat jij toch weer nét een andere implementatie hebt gebruikt van dezelfde concepten..oisyn schreef op dinsdag 6 februari 2024 @ 17:17:
De benchmark in Rust: https://play.rust-lang.or...9dca9444c25533f523c23dedb
De caveat is hier wel dat de eerste drie waarschijnlijk naar exact dezelfde assembly compileren.
.edit: correcthttps://compiler-explorer.com/z/KKMsM98Kj
En bedankt voor de verdere context, was mij niet helemaal duidelijk dat strings op die manier werden omgezet. Ik dacht dat het in ieder geval in JS al arrays van tekens waren, maar daar lijken de cijfers het niet mee eens te zijn
Maar je kunt niet zeggen dat een enkele if correspondeert met 1 CPU cycle en 3 ifs met 3 cycles. Ten eerste wordt een if doorgaans vertaald naar meerdere instructies (zoals een vergelijking en een sprong) en ten tweede hangt het van de architectuur en instructie af hoeveel cycles de CPU nodig heeft om de instructie uit te voeren.Oon schreef op woensdag 7 februari 2024 @ 07:13:
[...]
Als je na de 3e if een match hebt kun je meteen de rest skippen en een return doen, dat een theoretische winst kunnen opleveren t.o.v. voor ieder getal moeten delen. Dan zou je dus alleen het laatste cijfer van een getal moeten kunnen krijgen zonder alsnog ook te delen.
Het idee om naar het laatste cijfer van een getal te kijken om te bepalen of het getal even is gaat er vanuit dat je op een gemakkelijke manier over het laatste cijfer van het getal kunt beschikken. Dit hangt dus sterk af hoe je het getal in het geheugen hebt opgeslagen, of in de analoge wereld hoe je het hebt opgeschreven. Hoe bepaal je bijv. snel of XLVII een even getal is? In ieder geval niet door alleen naar het laatste cijfer te kijken.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Zeker in een high level taal als JS is het inderdaad niet zo dat een if conditie gelijk staat aan 1 CPU cycle, het ging mij meer om het feit dat daar wel winst te behalen valt (en niet zozeer hoeveel winst het precies is). Als je een if hebt met alleen een or erin en geen and dan zou netjes bij de eerste match de rest moeten worden genegeerd, en met een early return kun je dan al heel wat extra dingen overslaan.RayNbow schreef op woensdag 7 februari 2024 @ 08:06:
[...]
Maar je kunt niet zeggen dat een enkele if correspondeert met 1 CPU cycle en 3 ifs met 3 cycles. Ten eerste wordt een if doorgaans vertaald naar meerdere instructies (zoals een vergelijking en een sprong) en ten tweede hangt het van de architectuur en instructie af hoeveel cycles de CPU nodig heeft om de instructie uit te voeren.
Het idee om naar het laatste cijfer van een getal te kijken om te bepalen of het getal even is gaat er vanuit dat je op een gemakkelijke manier over het laatste cijfer van het getal kunt beschikken. Dit hangt dus sterk af hoe je het getal in het geheugen hebt opgeslagen, of in de analoge wereld hoe je het hebt opgeschreven. Hoe bepaal je bijv. snel of XLVII een even getal is? In ieder geval niet door alleen naar het laatste cijfer te kijken.
Ik denk verder dat Romeinse cijfers buiten deze discussie vallen, het ging mij er vooral om dat modulo bekend staat als traag en of dat niet sneller kan. Uiteindelijk is de modulo 'traag' (wat echt heel erg meevalt tenzij je met triljoenen iteraties werkt) omdat er een getal gedeeld wordt en hoe groter het getal hoe langer dat duurt, maar zoals nu wel duidelijk is (en in een tweede taal bevestigd door @.oisyn, waarvoor dank
De vraag is dus of er een manier is om het laatste cijfer in een getal te krijgen op een manier die sneller is dan een modulo langzaam is, zodat je op een lager aantal (bijv. duizend of een miljoen iteraties) al dat kantelpunt bereikt waar het sneller wordt dan het getal delen.
Daarnaast heb ik de originele YT video niet getest, misschien dat voor ieder getal een losse if-statement wel sneller kan zijn in JS, maar dat verwacht ik niet. Heb helaas even niet de tijd om dit mbv een test te onderbouwen, maar misschien dat ik dat vanmiddag nog even doe als niemand mij voor is
Het was een voorbeeld waarbij je niet zo snel het laatste cijfer van een getal kan vinden.Oon schreef op woensdag 7 februari 2024 @ 09:51:
Ik denk verder dat Romeinse cijfers buiten deze discussie vallen,
Omzetten naar een string hoeft niet langzaam te zijn. Als je getallen als BCD's zijn opgeslagen, heb je geen modulo nodig als je het getal wilt omzetten naar een string.maar zoals nu wel duidelijk is (en in een tweede taal bevestigd door @.oisyn, waarvoor dank) is een string omzetten ook langzaam.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Het is in JS nog veel abstracter dan een if conditie staat gelijk aan een bepaalde CPU operatie. Of een % controleert het laatste getal/binary value. In JS heb je geen idee waar de code naar vertaald wordt, misschien doet JS voor lage getallen wel een if statement op de achtergrond omdat het vaak voorkomt. Zelfs in het voorbeeld uit het filmpje in C geeft de schrijver aan dat het de compiler moet laten weten dat deze geen eigen optimalisaties moet uitvoeren.Oon schreef op woensdag 7 februari 2024 @ 09:51:
[...]
Zeker in een high level taal als JS is het inderdaad niet zo dat een if conditie gelijk staat aan 1 CPU cycle, het ging mij meer om het feit dat daar wel winst te behalen valt (en niet zozeer hoeveel winst het precies is). Als je een if hebt met alleen een or erin en geen and dan zou netjes bij de eerste match de rest moeten worden genegeerd, en met een early return kun je dan al heel wat extra dingen overslaan.
...
De vraag is dus of er een manier is om het laatste cijfer in een getal te krijgen op een manier die sneller is dan een modulo langzaam is, zodat je op een lager aantal (bijv. duizend of een miljoen iteraties) al dat kantelpunt bereikt waar het sneller wordt dan het getal delen.
De vraag of er dus sneller een isEven of isOdd gekregen kan worden in JS is dus enorm afhankelijk van de compiler/engine waarmee je dus nooit zeker weet of een optimalisatie wel echt een optimalisatie is. In je voorbeeld weet jij bijvoorbeeld dat het getal niet groter kan worden dan 999999 maar JS weet dat niet, als jij dan een snellere manier vindt geldt die misschien alleen voor deze opzet maar met een random getal niet meer. Als de compiler echt slim is zou deze zelfs kunnen zien dat er niets gedaan wordt met de returns van alle isEven/isOdd's en slaat het de berekening gewoon helemaal over en geeft je de tijd dat het kost om dat uit te vogelen.
https://play.rust-lang.or...8c45b5e33172f4b3b31395cc9. De bitwise AND is hier aanzienlijk (meer dan een factor 10) sneller dan MOD en DIV (die identiek performen).
Compiler explorer laat zien dat ze alle drie verschillend zijn: https://compiler-explorer.com/z/j3Kszos3x
.edit: oh nee, MOD en DIV zijn alsnog identiek. Gek genoeg heeft hij ze niet gemerged. Beide maken gebruik van de rest na de deling. Er zit dus geen vermenigvuldiging en een aftrekking in de DIV versie.
Misschien kan ik nog meer black-boxen.
.edit2: ja nu zijn ze echt alle drie verschillend: https://play.rust-lang.or...858761b8cbddb404cc7f66161. Perf verschil tussen MOD en DIV is alsnog niets. Ik zie in de assembly nu wel dat hij daadwerkelijk een vermenigvuldiging na de deling doet.
[ Voor 26% gewijzigd door .oisyn op 07-02-2024 11:55 ]
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.
Bij de string kan je bij de laatste byte ook een `and` uitvoeren op de laatste bit.
char '1' = 0x0110001b
char '2' = 0x0110010b
https://play.rust-lang.or...d4aff63f3169c59c35cc54870
Het valt me wel op dat de tijden niet erg stabiel zijn wanneer het om strings gaat. Mogelijk cache misses op CPU of omdat het een shared resource is?
[ Voor 47% gewijzigd door DevWouter op 07-02-2024 13:25 ]
"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
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.
Deze kwam er random uitflappen toen ik dit pakketje eens wou uittesten
Pleun van Grondelle
Ridder
Kampweg 11-s 2631VK Ossenzijl
(041) 7792700
Ridder

Raap mij even op graag!
Ook leuk dat er buitenlandse namen in staan zoals Koçak. Maar het script is zelfs intelligent geprogrammeerd dat het soms namen combineert met straatnamen. En zo krijg je ook bijvoorbeeld Koçaksingel.
Heel bijzonder omdat er volgens mij geen allochtoonse straatnamen bestaan. Maar het is random, dus hét kan. En wie weet gaat het een keer gebeuren, al hoef ik hier geen discussie over
[ Voor 27% gewijzigd door AW_Bos op 09-02-2024 13:17 ]
☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
Sowieso zijn leestekens tegenwoordig gewoon toegestaan en als er 1 vernoemd wordt naar een persoon dan pakken ze gewoon de spellingswijze die hij/zij hanteerd. Dus krijg je straten als "Brücknerstraat", "Henk Höftenstraat"
zo moeilijk is dat niet, gewoon verhuizen of een andere telefoon provider zoeken.Caelorum schreef op vrijdag 9 februari 2024 @ 14:24:
Tja, beter is het om even vooruit te denken inderdaad. Anders krijg je van dit soort grapjes: https://forum.kpn.com/mob...in-onze-straatnaam-514230
Sowieso zijn leestekens tegenwoordig gewoon toegestaan en als er 1 vernoemd wordt naar een persoon dan pakken ze gewoon de spellingswijze die hij/zij hanteerd. Dus krijg je straten als "Brücknerstraat", "Henk Höftenstraat"
Uit mijn hoofd hebben we hier in het dorp een Anne Frankplein, Bernhardstraat en Clausstraat.AW_Bos schreef op vrijdag 9 februari 2024 @ 13:10:
Heel bijzonder omdat er volgens mij geen allochtoonse straatnamen bestaan.
/f/image/9pMEWpKFbjAZS94RhiaPXCHk.png?f=fotoalbum_large)
Dit moet toch gewoon 1.0234375 zijn?
Oftewel: (1 + ((2 * 3) / ((2 ^ (2 ^ 3))) * (1 ^ 2)))
Oftewel:
1
2
3
4
5
6
7
| 2 * 3 = 6 2 ^ 3 = 8 2 ^ 8 = 256 6 / 256 = 0.0234375 1 ^ 2 = 1 0.0234375 * 1 = 0.0234375 1 + 0.0234375 = 1.0234375 |
Lekker warrig. Een aantal sites geven mij gelijk: https://www.calculatorsou.../math-equation-solver.php en een aantal de Windows rekenmachine: https://www.meracalculato...operations-calculator.php
Met dus de kern of het dit is: ((2 ^ 2) ^ 3) of dit (2 ^ (2 ^ 3))
Hmm, wikipedia heeft er een stukje over. Undefined dus

However, when using operator notation with a caret \(^\) or arrow (↑), there is no common standard.[25] For example, Microsoft Excel and computation programming language MATLAB evaluate a^b^c as (ab)c, but Google Search and Wolfram Alpha as a(bc). Thus 4^3^2 is evaluated to 4,096 in the first case and to 262,144 in the second case.
[ Voor 37% gewijzigd door CurlyMo op 09-02-2024 19:51 ]
Sinds de 2 dagen regel reageer ik hier niet meer
Maar blijkbaar is dat een conventie (niet een regel/wet), zie ook deze paragrafen op Wikipedia: Wikipedia: Exponentiation + Wikipedia: Order of operations
Net boven het stuk dat jij gequote hebt staat hoe het zou moeten werken als je het uitschrijft als superscript, en daaruit volgt toch redelijk dat het rechts associatief is. Maar blijkbaar zijn die regels anders opgevat als je het uitschrijft met ^ of ** (zoals je zelf ook al quote). Heerlijk consistent weer...
There's no place like 127.0.0.1
:fill(white):strip_exif()/f/image/Oyo2Nqqkz0G3BVdgzVyHGv04.png?f=user_large)
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Verwijderd
SSE is leuk, maar heeft beperkingen. Als je 7 tabs opent naar jouw CMS (of een andere website met SSE) dan zal nummer 7 kapot gaan. Zelf hanteer ik altijd websockets, dan fallback naar SSE+POST en dan naar longpolling+POST.Verwijderd schreef op woensdag 14 februari 2024 @ 16:03:
Gebruiken jullie sse al? Ben voor mijn cms aan het kijken naar https://developer.mozilla.../Using_server-sent_events en dat ziet er veel makkelijker uit dan sockets. En je kan van elk server event een cliënt event maken. Is wel read only, maar met een http post zou je het wellicht kunnen updaten. Zo kun je event-wise je ui gaan updaten ?
"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
Verwijderd
Ik las in mijn artikel:DevWouter schreef op woensdag 14 februari 2024 @ 16:13:
[...]
SSE is leuk, maar heeft beperkingen. Als je 7 tabs opent naar jouw CMS (of een andere website met SSE) dan zal nummer 7 kapot gaan. Zelf hanteer ik altijd websockets, dan fallback naar SSE+POST en dan naar longpolling+POST.
Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE...
Web sockets met php, heb je ook trothling e.d. erin zitten want anders ben je lijkt me zeer beperkt met het aantal ?
Heb apache2 met http2, dan is het 100 na handshake, had ik gelezen
[ Voor 39% gewijzigd door Verwijderd op 14-02-2024 16:24 ]
Dat is inderdaad enkel een probleem met HTTP1, maar ik zou me met PHP + SSE ook druk maken om de server-side schaling: ik zie zo snel niet hoe je SSE zou opzetten in een fast-gci applicatie waarin je niet een gci-proces per client openhoud. PHP is puur gemaakt voor kort lopende request, als je daarin een while(true) gaat doet om later nog events te sturen dan ben ik bang dat je server heel veel openstaande processen gaat hebben.Verwijderd schreef op woensdag 14 februari 2024 @ 16:17:
[...]
Ik las in mijn artikel:
Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE...
Web sockets met php, heb je ook trothling e.d. erin zitten want anders ben je lijkt me zeer beperkt met het aantal ?
Heb apache2 met http2, dan is het 100 na handshake, had ik gelezen
Verwijderd
Voor mijn backend en cms systeem. Als je een eventsource per app aanmaakt kan die app er voor elke user hetzelfde eruit zien. Je hebt wat meer processen, maar ik wil er inderdaad een rate-limiter opzetten die per gebruiker is in te stellen. Het moet zeg maar dom updates gaan sturen met eventueel data (json) of javascript of css. De verbinding wordt niet continue vol belast en ik wil er bijvoorbeeld voor YouTube download app, de voortgang bijhouden van processen. Als dat klaar is, kan er worden geclosed. Het cms zal niet door veel gebruikers gelijkertijd gedraaid worden. Maar ik wil graag dat 2 admins hetzelfde gaan zien als ze tegelijkertijd zijn ingelogd op hetzelfde gedeelte (file manager bijvoorbeeld, uploads van beide), kan ik met mijn klanten iets uitleggen, live updates.RagingPenguin schreef op donderdag 15 februari 2024 @ 17:31:
[...]
Dat is inderdaad enkel een probleem met HTTP1, maar ik zou me met PHP + SSE ook druk maken om de server-side schaling: ik zie zo snel niet hoe je SSE zou opzetten in een fast-gci applicatie waarin je niet een gci-proces per client openhoud. PHP is puur gemaakt voor kort lopende request, als je daarin een while(true) gaat doet om later nog events te sturen dan ben ik bang dat je server heel veel openstaande processen gaat hebben.
Bedenk me net dan audio over zo'n kanaal ook leuk kan zijn, dan heb je radio, hetzelfde fragment op elke luisteraar....
[ Voor 5% gewijzigd door Verwijderd op 15-02-2024 18:39 ]

Blijkt dat AI ook geen bal snapt van 20 jaar oude legacy spaghetti code
Wel leuk voor het genereren van nieuwe code, maar ook daarbij moet je het nogal aan het handje vasthouden. Tot op het punt dat je gaat twijfelen wat sneller is... het aan de AI uitleggen of het zelf ff schrijven.
Veelgehoorde tip bij AI... "provide context", moet die context wel te ontcijferen zijn lol. Vaak ben ik zelf uren bezig de code te lezen en aantekeningen maken voordat ik het ga refactoren / verbeteren.
/explain voegt daarbij niet veel toe.
De grap is dat ontzettend veel bedrijfskritische code 1 grote puinhoop is bij veel organisaties. Daar heb je wel mensen voor nodig die de context begrijpen en überhaupt aan een AI kunnen vertellen.
Maar goed, het is wel leuk speelgoed en ik zal ermee blijven pielen om te kijken of het beter wordt, of dat ikzelf beter word in het verzinnen van de juiste prompts en context bieden.
Ask yourself if you are happy and then you cease to be.
Daarnaast zit er ook generieke prompting en wat geavanceerdere autocomplete in.
Op zich valt het me niet tegen. Met name het genereren van een commit message werkt heel aardig. De refactoring suggesties (met niet alleen een wat, maar ook een waarom) zijn vaak best aardig. Unit tests wisselen van kwaliteit net als de autocomplete en custom prompts.
Het staat of valt allemaal wel een beetje met hoe "begrijpelijk" je bestaande code is. Van totale spaghetti met onbegrijpelijke naamgeving maakt AI ook niet veel.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Github CoPilot komt gewoon meestal met net niet goede code aanzetten in mijn geval. Of vol met fouten, of niet wat ik wil.
Dat ligt, net als bij ChatGPT, aan je invoer. Bullshit in = bullshit out. Ik wil niet zeggen dat je code slecht is, maar je moet Copilot vaak eerst even helpen. Als je een begin maakt met goede code, dan zal hij dat - in de zelfde stijl - aanvullen met goede code. En hoe specifieker je bent in naamgeving van de classes/functies, en het commentaar daar bij, hoe beter het resultaat. Het probleem is vaak dat men een beknopt zinnetje typt wat op 400 verschillende manieren geinterpreteerd kan worden, en dan gaan klagen dat het een slecht resultaat levert.Caelorum schreef op maandag 4 maart 2024 @ 18:45:
Ik vind GitHub copilot ook echt enorm onder de maat vergeleken met chatgpt.
edit: daarbij moet je Copilot ook meer zien als een autocomplete op steroids.
[ Voor 5% gewijzigd door ThomasG op 04-03-2024 21:20 ]
En ik ben overigens al best een tijdje vrij actief. Ik vergelijk ook veel tussen de tools en hou mezelf ook actief op de hoogte op dit gebied. Het heeft mij productiever dan ooit gemaakt. Maar GitHub CoPilot is echt een uitzondering hierin. Die is echt bar slecht.
Zo heb ik recent nog een tool volledig aan de hand van jetbrains ai en chatgpt gemaakt welke in de Azure DevOps marketplace staat. Minder dan 3% code is rechtstreeks geschreven.
Overigens de live demo van GitHub personeel die ik vorig jaar heb gezien was ook lachwekkend. Ze hebben dat ding 3 dingen laten doen en geen 1 van die op voorhand gekozen taken volbracht het ding goed, waarbij het 1 keer op de fouten werd gewezen en doodleuk de fout nog een keer herhaalde. Mooi man.
En ja ik weet dat alle LLMs fouten kunnen maken, maar bij mij steekt GitHub CoPilot daar wel echt bovenuit.
[ Voor 5% gewijzigd door Caelorum op 04-03-2024 21:30 ]
@Caelorum De reden waarom ChatGPT beter werkt is omdat het meer processor kracht krijgt. GitHub CoPilot draait een lichter model en krijgt minder processorkracht (logisch, je maakt er continue gebruik van). Onder water maakt zowel ChatGPT als CoPilot gebruik van een vergelijkbaar model.
---
Dat gezegd te hebben begin ik steeds minder fan te worden van AI. Voor simpel werk is het goed genoeg, maar ik krijg steeds vaker suggesties die ik expliciet niet wil. Het helpt ook niet dat ik vaak aan code werk dat opgeschoond moet worden. Een tweede probleem is dat ik wel merk dat mijn actieve kennis steeds minder wordt. Ik begin zelfs serieus na te denken om actief mijn kennis weer bij te werken (en dat terwijl ik opleider ben).

"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
Onder andere. Ze gebruiken ook nog wel wat andere modellen die ze ook zelf gemaakt hebben. Ik denk dat meer gespecialiseerde modellen zeker toegevoegde waarde hebben. Ja een groot model met achterlijk veel parameters zal op een bredere range van taken degelijk kunnen presteren, maar kleinere modellen die specifieker op taken zijn toegespitst kunnen vaak nog beter werken voor die specifieke taken.Caelorum schreef op maandag 4 maart 2024 @ 21:12:
JetBrains AI assistant gebruikt dan ook OpenAI als backing dienst, dus dan gaat het wel ja.
Github CoPilot komt gewoon meestal met net niet goede code aanzetten in mijn geval. Of vol met fouten, of niet wat ik wil.
Wat JetBrains verder nog doet is handig gebruik maken van de CST / AST om zoveel mogelijk relevante context mee te kunnen geven. Dat zorgt er ook weer voor dat je prompt beter is dan wanneer je zelf stukken code moet knippen en plakken in je prompt.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
We leven in een samenleving waar het steeds makkelijker word omdat dingen voor je gedaan wordt. Als mens vinden we dat fijn, we zijn daar steeds naar op zoek want dat bespaart energie, maar het heeft ook een nadeel.DevWouter schreef op maandag 4 maart 2024 @ 21:55:
[...]
Dat gezegd te hebben begin ik steeds minder fan te worden van AI. Voor simpel werk is het goed genoeg, maar ik krijg steeds vaker suggesties die ik expliciet niet wil. Het helpt ook niet dat ik vaak aan code werk dat opgeschoond moet worden. Een tweede probleem is dat ik wel merk dat mijn actieve kennis steeds minder wordt. Ik begin zelfs serieus na te denken om actief mijn kennis weer bij te werken (en dat terwijl ik opleider ben).
Zitten, suiker, gebruik van LLM: Het geeft ons als mens de kans om iets te "offloaden": waarom staan als ik kan zitten? Waarom al die groente eten, als zo'n snoepje meer beloning geeft? Waarom zelf moeite doen als zo'n chatbot de samenvatting kan maken?
Wij zijn als mens steeds op zoek naar zulke handigheidjes, want daardoor hebben we meer tijd/energie voor andere zaken. Maar het feit dat dingen ons zo weinig moeite meer kosten, komt met het nadeel dat dit op de langere termijn parten gaat spelen.
Je krijgt dan "we zitten teveel", "we eten teveel suiker" en "we vertrouwen teveel op LLM". Juist het feit dat iets moeite kost, is een signaal dat je je lichaam uitdaagt en daardoor traint. Door teveel op AI te is de kans groter dat je hierdoor te weinig traint. Hierdoor wordt je dan weer afhankelijker van die tools, waardoor je nóg minder gaat doen.
Dus juist dat iets moeite kost (lopen en staan/groente eten/zelf samenvatting schrijven) is een teken dat je iets goed doet. Het zoeken naar de 'snelle beloning' is weliswaar evolutionair logisch, maar op de langere termijn niet perse gezond voor je.
Einstein: Mijn vrouw begrijpt me niet
Euh? Volgens mij zou het juist heel gezond zijn voor mensen als de meeste kantoorbanen geautomatiseerd zouden worden. Minder uren achter een schermpje zitten.DaFeliX schreef op dinsdag 5 maart 2024 @ 07:24:
[...]
We leven in een samenleving waar het steeds makkelijker word omdat dingen voor je gedaan wordt. Als mens vinden we dat fijn, we zijn daar steeds naar op zoek want dat bespaart energie, maar het heeft ook een nadeel.
Zitten, suiker, gebruik van LLM: Het geeft ons als mens de kans om iets te "offloaden": waarom staan als ik kan zitten? Waarom al die groente eten, als zo'n snoepje meer beloning geeft? Waarom zelf moeite doen als zo'n chatbot de samenvatting kan maken?
Wij zijn als mens steeds op zoek naar zulke handigheidjes, want daardoor hebben we meer tijd/energie voor andere zaken. Maar het feit dat dingen ons zo weinig moeite meer kosten, komt met het nadeel dat dit op de langere termijn parten gaat spelen.
Je krijgt dan "we zitten teveel", "we eten teveel suiker" en "we vertrouwen teveel op LLM". Juist het feit dat iets moeite kost, is een signaal dat je je lichaam uitdaagt en daardoor traint. Door teveel op AI te is de kans groter dat je hierdoor te weinig traint. Hierdoor wordt je dan weer afhankelijker van die tools, waardoor je nóg minder gaat doen.
Dus juist dat iets moeite kost (lopen en staan/groente eten/zelf samenvatting schrijven) is een teken dat je iets goed doet. Het zoeken naar de 'snelle beloning' is weliswaar evolutionair logisch, maar op de langere termijn niet perse gezond voor je.
Voor de rest zijn we net pakweg een jaartje onderweg met de AI tools. Dat is zegmaar de iPhone 1-fase onder dr smartphones, als we niet in de Nokia-fase zitten.
Veel van de moeite die het kost is gewoon repetitief werk, daarom komt er elke dag een nieuw framework/library/tool uit die het belooft te verbeteren. Niet elke developer werkt bovendien aan superspannende zaken. Heb teams zien ploeteren om troep legacy te onderhouden of om kleine aanpassingen aan een webshop te doen. Zonde van je hersencapaciteit of levensjaren. Ik juich AI toe.
Ik gebruik AI wel gewoon voor de vlugge autocompletes, eigenlijk meer een vervanging voor de oudere deep assoc plugins en dingen als Kite of TabNine voordat we ChatGPT kregen, maar niet voor volledige lappen code. Daar is het gewoon nog niet klaar voor.DevWouter schreef op maandag 4 maart 2024 @ 21:55:
Dat gezegd te hebben begin ik steeds minder fan te worden van AI. Voor simpel werk is het goed genoeg, maar ik krijg steeds vaker suggesties die ik expliciet niet wil. Het helpt ook niet dat ik vaak aan code werk dat opgeschoond moet worden. Een tweede probleem is dat ik wel merk dat mijn actieve kennis steeds minder wordt. Ik begin zelfs serieus na te denken om actief mijn kennis weer bij te werken (en dat terwijl ik opleider ben).
Nu gebruik ik TabNine nog steeds, en hun AI-model (dat natuurlijk inmiddels weer ergens gebaseerd is op het werk van OpenAI) is wel echt goed, maar in tegenstelling tot GitHub CoPilot wel enigszins beperkt tot wat nuttig is binnen je eigen codebase en dat is fijn. De AI van JetBrains is daarentegen dan weer té beperkt en dan merk je dat je het toch gaat missen.
Ik heb liever minder AI-resultaten en alleen maar goede AI-resultaten, dan meer resultaten waarvan de helft onbruikbaar is, dat veroorzaakt alleen ruis en dan sluipt er toch her en der wel wat stinkende lage kwaliteit code naar binnen.
En het zijn dan ook niet de dingen die je expliciet niet wil die gevaarlijk zijn; die zijn wel vervelend, maar die zie je goed. Het zijn de dingen die je zelf toch nét wat netter zou uitvoeren die je stiekem wat sneller accepteert omdat je ze voorgeschoteld krijgt die gevaarlijk zijn.
Hier ben ik het volledig mee eens. Het aantal keren dat ik wil dat AI gewoon aangeeft van "nope, dat snap ik niet" ipv een poging waagt neemt telkens toe. Ik heb soms het idee dat ze dusdanig gefocused zijn op antwoord *geven* dat ze geen *antwoord* geven.Oon schreef op dinsdag 5 maart 2024 @ 08:55:
[...]
Ik heb liever minder AI-resultaten en alleen maar goede AI-resultaten, dan meer resultaten waarvan de helft onbruikbaar is, dat veroorzaakt alleen ruis en dan sluipt er toch her en der wel wat stinkende lage kwaliteit code naar binnen.
En het zijn dan ook niet de dingen die je expliciet niet wil die gevaarlijk zijn; die zijn wel vervelend, maar die zie je goed. Het zijn de dingen die je zelf toch nét wat netter zou uitvoeren die je stiekem wat sneller accepteert omdat je ze voorgeschoteld krijgt die gevaarlijk zijn.
"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
"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 het met je eens dat bepaalde repetitieve taken prima geautomatiseerd kunnen worden (daar zijn wij developers errrug goed inBarôZZa schreef op dinsdag 5 maart 2024 @ 08:44:
[...]
Euh? Volgens mij zou het juist heel gezond zijn voor mensen als de meeste kantoorbanen geautomatiseerd zouden worden. Minder uren achter een schermpje zitten.
Voor de rest zijn we net pakweg een jaartje onderweg met de AI tools. Dat is zegmaar de iPhone 1-fase onder dr smartphones, als we niet in de Nokia-fase zitten.
Veel van de moeite die het kost is gewoon repetitief werk, daarom komt er elke dag een nieuw framework/library/tool uit die het belooft te verbeteren. Niet elke developer werkt bovendien aan superspannende zaken. Heb teams zien ploeteren om troep legacy te onderhouden of om kleine aanpassingen aan een webshop te doen. Zonde van je hersencapaciteit of levensjaren. Ik juich AI toe.
Het gaat mij er meer om dat stukje "denken" wat soms moeite kost, en om aan te geven dat dit juist een teken is dat je jouw brein gezond houd door iets lastigs te doen. En ook de wens uitspreken dat wij als samenleving kritisch zijn (en blijven) op dingen die handig zijn - er zitten nu eenmaal ook nadelen aan
Einstein: Mijn vrouw begrijpt me niet
GitHub Copilot komt op mij over als "ik ben een tekst generator die geen kennis van de code heeft". Hij zegt maar wat.Caelorum schreef op maandag 4 maart 2024 @ 21:12:
JetBrains AI assistant gebruikt dan ook OpenAI als backing dienst, dus dan gaat het wel ja.
Github CoPilot komt gewoon meestal met net niet goede code aanzetten in mijn geval. Of vol met fouten, of niet wat ik wil.
Soms lijkt hij de intentie te snappen, maar kan de code die hij genereert helemaal niet werken omdat er properties gevuld worden die niet bestaan etc.
Het slaat echt nergens op soms.
Ask yourself if you are happy and then you cease to be.
De ingebouwde auto complete van Visual Studio (intellicode, ook "AI") werkt eigenlijk beter dan Copilot, als je het puur als auto complete zou gebruiken.ThomasG schreef op maandag 4 maart 2024 @ 21:18:
[...]
edit: daarbij moet je Copilot ook meer zien als een autocomplete op steroids.
Maar het interessante vind ik juist als er hele blokken code worden gegenereerd. Ze slaan alleen vaak nergens op helaas. Alsof een minderjarige Indiër het voor je maakt.
[ Voor 20% gewijzigd door Lethalis op 05-03-2024 18:25 ]
Ask yourself if you are happy and then you cease to be.
De legacy code die ik vaak refactor / verbeter is vooral procedureel en bevat veel afkortingen, of Nederlands en Engels door elkaar heen.ThomasG schreef op maandag 4 maart 2024 @ 21:18:
[...]
Dat ligt, net als bij ChatGPT, aan je invoer. Bullshit in = bullshit out. Ik wil niet zeggen dat je code slecht is, maar je moet Copilot vaak eerst even helpen.
Copilot wordt er niet wijzer van

Zelfs het Nederlands is niet consistent. Een oud collega die nu met pensioen is, weigerde bijvoorbeeld woorden met een c te schrijven want dat hoorde niet (dus faktuur ipv factuur etc)
Ask yourself if you are happy and then you cease to be.
Daarvoor is hij in zijn tijd ook niet naar skhool gegaan. Dit terwijl zijn ouders daar wel kentjes aan besteden. Gelukkig staat er geen kelstraf op want dat soort volk is zijn klubje niet. Maar hij is dan wel konsequent en volgens zijn kafebaas soms moet je door de zure kitroen snijden om daar limonade van te maken.Lethalis schreef op dinsdag 5 maart 2024 @ 18:45:
Zelfs het Nederlands is niet consistent. Een oud collega die nu met pensioen is, weigerde bijvoorbeeld woorden met een c te schrijven want dat hoorde niet (dus faktuur ipv factuur etc)
(Overigens neig ik er soms toe om "U" vaak met hoofdletter te schrijven, maar dat was al lang achterhaald voordat ik geboren ben).
"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
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.