mboost-dp1
When DeepMind’s ‘AlphaCode’ Competed Against Human Programmers
Meget interessant. Men problembeskrivelsen er væsentlig længere end løsningen, og der blev brugt petaflop DAGE på projektet. Så det virker ikke specielt praktisk til real world anvendelse endnu.
Jeg fornemmer også at systemet overtrænes til en bestemt type opgave, a'la "regn de sidste års eksamenssæt intensivt et par dage før eksamen" teknikken, som virker ekstremt godt, men kun til at bestå eksamen, ikke til ret meget andet.
Men det er da muligt at AI går hen og bliver en form for assistent man kan give simple afgrænsede programmeringsopgaver. Men de større tanker vedrørende systemdesign og arkitektur hænger vi mennesker nok på lidt endnu for at sige det mildt.
Jeg fornemmer også at systemet overtrænes til en bestemt type opgave, a'la "regn de sidste års eksamenssæt intensivt et par dage før eksamen" teknikken, som virker ekstremt godt, men kun til at bestå eksamen, ikke til ret meget andet.
Men det er da muligt at AI går hen og bliver en form for assistent man kan give simple afgrænsede programmeringsopgaver. Men de større tanker vedrørende systemdesign og arkitektur hænger vi mennesker nok på lidt endnu for at sige det mildt.
#2
Det er netop interessant men måske ikke så lovende.
Jeg tror faktisk at det er en blindgyde.
Hvis jeg har forstået beskrivelsen rigtigt så arbejder programmet ikke som et menneske. Et menneske udvikler problem->design->implementering og beslutninger undervejs træffes udfra et relativt beskedent antal kriterier mellem ganske få valg mulighder. Som jeg læser det oplæres det her software med et stor antal problemer og løsninger og når den får et nyt problem som det skal løse så sammenholder det problemet beskrivelsen med tidligere problemer og klasker diverse kode fragmenter sammen og tester så om de virker.
Det er samme princip som de dårligste 10% af menneskelige udviklere bruger. De kopierer lidt kode fra den eksistrende kode base og kopierer lidt kode fra StackOverflow baseret på problem beskrivelsen og så prøver de om det virker og gør det ikke så prøver de med noget andet kopieret kode.
Da AlphaCode kan lave det på sekunder som det et menneske er dage om at lave, så er slut resultatet ikke helt dårligt. Den kan på et par dage lave det som en dårlig udvikler ville skulle bruge hundredevis af år på.
Men grundliggende er tilgangen forkert. Og jeg tror ikke på at det nogensinde vil kunne producere en god udvikler. Det vil give verdens suverænt bedste uduelige udvikler!!
Problemstillingen kendes fra skak programmer omend konklusionen her er anderledes.
Tilbage i 70'erne var der mange inklusive Mihail Botvinnik som arbejede på at udvikle skak-programmer som fungerede ligesom en menneskelig skakspiller.
Det opgav man siden og skiftede til ren brute force. Og i de senere år blev de matchet af kombinationen af lidt brute force og AI til stillingsvurdering - populariseret af AlphaZero (som er i familie med AlphaCode).
skak : 20 træk muligheder og 100 halvtræk => 20^100 muligheder
programmer : 256 mulige instruktioner og 10000000 instruktioner i stort program => 256^10000000 muligheder
Så hvis vi sammneligner skak med software udvikling:
muligheder : 20^100 <=> 256^10000000
emulere menneske : opgivet i 70'erne <=> uprøvet
ren brute force : bedre end de bedste mennesker <=> håbløst
lidt brute froce + AI : lidt bedre måske bedre end ren brute force <=> ?
så gætter jeg på at ? betyder lidt bedre måske bedre end håbløst!
:-)
Det er netop interessant men måske ikke så lovende.
Jeg tror faktisk at det er en blindgyde.
Hvis jeg har forstået beskrivelsen rigtigt så arbejder programmet ikke som et menneske. Et menneske udvikler problem->design->implementering og beslutninger undervejs træffes udfra et relativt beskedent antal kriterier mellem ganske få valg mulighder. Som jeg læser det oplæres det her software med et stor antal problemer og løsninger og når den får et nyt problem som det skal løse så sammenholder det problemet beskrivelsen med tidligere problemer og klasker diverse kode fragmenter sammen og tester så om de virker.
Det er samme princip som de dårligste 10% af menneskelige udviklere bruger. De kopierer lidt kode fra den eksistrende kode base og kopierer lidt kode fra StackOverflow baseret på problem beskrivelsen og så prøver de om det virker og gør det ikke så prøver de med noget andet kopieret kode.
Da AlphaCode kan lave det på sekunder som det et menneske er dage om at lave, så er slut resultatet ikke helt dårligt. Den kan på et par dage lave det som en dårlig udvikler ville skulle bruge hundredevis af år på.
Men grundliggende er tilgangen forkert. Og jeg tror ikke på at det nogensinde vil kunne producere en god udvikler. Det vil give verdens suverænt bedste uduelige udvikler!!
Problemstillingen kendes fra skak programmer omend konklusionen her er anderledes.
Tilbage i 70'erne var der mange inklusive Mihail Botvinnik som arbejede på at udvikle skak-programmer som fungerede ligesom en menneskelig skakspiller.
Det opgav man siden og skiftede til ren brute force. Og i de senere år blev de matchet af kombinationen af lidt brute force og AI til stillingsvurdering - populariseret af AlphaZero (som er i familie med AlphaCode).
skak : 20 træk muligheder og 100 halvtræk => 20^100 muligheder
programmer : 256 mulige instruktioner og 10000000 instruktioner i stort program => 256^10000000 muligheder
Så hvis vi sammneligner skak med software udvikling:
muligheder : 20^100 <=> 256^10000000
emulere menneske : opgivet i 70'erne <=> uprøvet
ren brute force : bedre end de bedste mennesker <=> håbløst
lidt brute froce + AI : lidt bedre måske bedre end ren brute force <=> ?
så gætter jeg på at ? betyder lidt bedre måske bedre end håbløst!
:-)
#3 Ja, da en AI kunne slå de bedste skakspillere første gang troede folk at Skynet-agtige computere var klar til at overtage menneskeheden, fordi AI allerede var smartere end mennesker. Det er selvfølgelig fuldstændig misforstået.
Jeg tror dog godt at AI ville kunne bruges til mere og mere avancerede programmeringsassistenter der kunne finde og hjælpe med typiske fejl mens man skriver koden, og måske finde og indpasse boilerplate kode meget effektivt.
Da AlphaCode kan lave det på sekunder som det et menneske er dage om at laveDer står at det tog hundredevis af petaflop data at træne AlphaCode. Men jeg synes ikke det fremgår hvor meget juice det tager at bruge det? Jeg er ikke sikker på det bare er sekunder på en lokal computer.
Det vil give verdens suverænt bedste uduelige udvikler!!Ja, skulle man bruge et AI system til at skrive kode ville det være et must at arbejde test driven, og lade AI komme frem til kode der løser alle test cases. Og selv i den situation vil man ikke vide sig sikker om koden egentlig implementerer den ønskede logik eller bare leverer de rigtige svar, så jeg er enig, det er nok en blindgyde.
Jeg tror dog godt at AI ville kunne bruges til mere og mere avancerede programmeringsassistenter der kunne finde og hjælpe med typiske fejl mens man skriver koden, og måske finde og indpasse boilerplate kode meget effektivt.
larsp (4) skrev:#3 Ja, da en AI kunne slå de bedste skakspillere første gang troede folk at Skynet-agtige computere var klar til at overtage menneskeheden, fordi AI allerede var smartere end mennesker. Det er selvfølgelig fuldstændig misforstået.
AI er ikke engang nødvendig - banal brute force er god nok til at slå menneskelige skakspillere med hurtige nok computere.
larsp (4) skrev:Da AlphaCode kan lave det på sekunder som det et menneske er dage om at laveDer står at det tog hundredevis af petaflop data at træne AlphaCode. Men jeg synes ikke det fremgår hvor meget juice det tager at bruge det? Jeg er ikke sikker på det bare er sekunder på en lokal computer.
Sikkert ikke. Men jeg vil tro at det er mere relevant at tælle træning med. Med virkelige opgaver tror jeg at der vil skulle trænes specifikt for hver opgave, fordi opgaverne er for forskellige i natur.
larsp (4) skrev:Det vil give verdens suverænt bedste uduelige udvikler!!Ja, skulle man bruge et AI system til at skrive kode ville det være et must at arbejde test driven, og lade AI komme frem til kode der løser alle test cases. Og selv i den situation vil man ikke vide sig sikker om koden egentlig implementerer den ønskede logik eller bare leverer de rigtige svar, så jeg er enig, det er nok en blindgyde.
Verifikation via test er langtfra en sikker process. Der er i praksis uendeligt mange test scenarier.
De har tal i kilden.
One thing they discovered? There’s a problem with the currently available datasets of problems and solutions from programming competitions. At least 30% of those programs pass all the test cases — but are not actually correct.
larsp (4) skrev:
Jeg tror dog godt at AI ville kunne bruges til mere og mere avancerede programmeringsassistenter der kunne finde og hjælpe med typiske fejl mens man skriver koden, og måske finde og indpasse boilerplate kode meget effektivt.
Jeg tror mere på AI til fejlfinding. At finde ud af om specifikt input vil give buffer overrun, division by zero eller resultere i injection er en langt mere computer venlig opgave.
AI kunne uden tvivl forbedre eksisterende kode analyse værktøjer.
https://www.vajhoej.dk/arne/articles/devproc.html
Det er faktisk et vanskeligt emne. Der er skrevet meget om programmering i alle mulige programmerings sprog og frameworks. Der er skrevet meget om udviklings metodologier, use cases, UML, unit test etc.. Men der er ikke skrevet så meget om hvordan man kommer fra et problem til noget kode.
Det er faktisk et vanskeligt emne. Der er skrevet meget om programmering i alle mulige programmerings sprog og frameworks. Der er skrevet meget om udviklings metodologier, use cases, UML, unit test etc.. Men der er ikke skrevet så meget om hvordan man kommer fra et problem til noget kode.
#9 og #10
Men man bliver naturligvis præget af at arbejde i en stor virksomhed. Der er nogle forskelle på små og store virksomheder.
For 15 år siden købte det firma jeg arbejdede for en mindre virksomhed med ca. 150 ansatte. De kunne altid træffe en hurtig beslutning. Man spurgte bare direktøren som også var hovedaktionær og så traf han en beslutning på stedet. Men vi var 6000 ansatte og den metode ville ikke fungere for os, så der var processer og et ledelses hiraki.
Og idag er jeg en del af 11000 ansatte.
Men det kan værre værre. En ex-IBM'er fortalte mig engang at i IBM var man indstillet på at nyansatte skulle bruge 3 måneder på at lære organisation og processer inden de begyndte at producere noget.
Men man bliver naturligvis præget af at arbejde i en stor virksomhed. Der er nogle forskelle på små og store virksomheder.
For 15 år siden købte det firma jeg arbejdede for en mindre virksomhed med ca. 150 ansatte. De kunne altid træffe en hurtig beslutning. Man spurgte bare direktøren som også var hovedaktionær og så traf han en beslutning på stedet. Men vi var 6000 ansatte og den metode ville ikke fungere for os, så der var processer og et ledelses hiraki.
Og idag er jeg en del af 11000 ansatte.
Men det kan værre værre. En ex-IBM'er fortalte mig engang at i IBM var man indstillet på at nyansatte skulle bruge 3 måneder på at lære organisation og processer inden de begyndte at producere noget.
arne_v (12) skrev:#9 og #10
Men man bliver naturligvis præget af at arbejde i en stor virksomhed. Der er nogle forskelle på små og store virksomheder.
For 15 år siden købte det firma jeg arbejdede for en mindre virksomhed med ca. 150 ansatte. De kunne altid træffe en hurtig beslutning. Man spurgte bare direktøren som også var hovedaktionær og så traf han en beslutning på stedet. Men vi var 6000 ansatte og den metode ville ikke fungere for os, så der var processer og et ledelses hiraki.
Og idag er jeg en del af 11000 ansatte.
Men det kan værre værre. En ex-IBM'er fortalte mig engang at i IBM var man indstillet på at nyansatte skulle bruge 3 måneder på at lære organisation og processer inden de begyndte at producere noget.
Fra ESR:
Lion food
[IBM] Middle management or HQ staff (or, by extension, administrative drones in general). From an old joke about two lions who, escaping from the zoo, split up to increase their chances but agree to meet after 2 months. When they finally meet, one is skinny and the other overweight. The thin one says: “How did you manage? I ate a human just once and they turned out a small army to chase me — guns, nets, it was terrible. Since then I've been reduced to eating mice, insects, even grass.” The fat one replies: “Well, I hid near an IBM office and ate a manager a day. And nobody even noticed!”
#13
Variant:
Variant:
Five cannibals get appointed as programmers in an IT company. During the welcoming ceremony the boss says: "You're all part of our team now. You can earn good money here, and you can go to the company canteen for something to eat. So don't trouble the other employees".
The cannibals promise not to trouble the other employees.
Four weeks later the boss returns and says: "You're all working very hard, and I'm very satisfied with all of you. One of our cleaners has disappeared however. “Do any of you know what happened to her?"
The cannibals disavow all knowledge of the missing cleaner.
After the boss has left, the leader of the cannibals says to the others:
"Which of you idiots ate the cleaner?" A hand rises hesitantly, to which the leader of the cannibals says:
"You fool! For four weeks we've been eating Team Leaders, Managers, and Project Managers so no-one would notice anything, and you have to go and eat the cleaner!"
arne_v (11) skrev:#7
Nogle kommentarer?
Der er et C# og et php/html eksempel. Det slog mig at den nuværende trendy løsning nok ville være et Electron program. Det kunne være sjovt at have det også at sammenligne med. Hello world er ikke så slem igen: https://www.electronjs.org/docs/latest/tutorial/qu...
Ellers får eksemplerne mig til at tænke på de gode gamle VB6 dage. Da jeg var i VB topform kunne jeg smække sådan et program sammen på nærmest få minutter. Og 5 minutter mere til at lave en nasty Access database. De Microsoft tools fra dengang som alle elsker at hade var bare ekseptionelt lette at gå til og hurtige at udvikle i.
Man kunne lave delvist funktionelle mock-ups i VB6 hurtige end at tegne diagrammerne.
... hvilket jo førte til at en masse cowboy udviklere lavede en masse skrald med de tools. Og Access startede vitterlig som en joke af en database, men den var stadigvæk fin nok til små systemer.
Nu har C# og Visual Studio nok taget stafetten i denne kategori og de er en fabelagtig udviklingsplatform. Men der mangler stadig den der instant gratifikation fornemmelse man fik i VB6 fordi compile tog ca. 0.0 sekunder og det intuitive i at alle funktionerne var direkte knyttet til de visuelle elementer, og uden halv-hemmelige form builder filer, der skulle refaktoreres hele tiden med bøvl til følge.
Immediate vinduet i VB6 var også genialt. Indsæt et break i koden og test matematikken eller funktionerne direkte. Det var helt Python agtigt. Forud for sin tid. Stadig uovergået hvad angår brugervenlighed (for begynder udviklere).
#15
Jeg tror ikke at jeg har evnerne til at lave det i Electron. Men jeg har det helt fint med at koden er en anelse gammeldags. Simpel kode som ikke kræver nyeste er det som passer i sammenhængen.
Ja. Der skete et eller andet med RAD tools i 00'erne. Tilbage i 90'erne havde man Access, VB6, Delphi og lidt mere eksotisk Jyacc (JAM & JPL). Men VB6 blev "erstattet" af VB.NET som reelt er noget helt andet, Delphi brugen styrtdykkede og Jyacc skiftede status fra eksotisk til uddød. Og selv Access som applikation er vel dykket i brug.
(jeg har lavet rigtigt meget Access, noget Jyacc, en lille smule Delphi og intet VB6)
WinForms, WPF, diverse Swing WYSIWYG editorer og divese web WYSIWYG editorer har aldrig nået samme niveau af nemhed.
Jeg tror ikke at jeg har evnerne til at lave det i Electron. Men jeg har det helt fint med at koden er en anelse gammeldags. Simpel kode som ikke kræver nyeste er det som passer i sammenhængen.
Ja. Der skete et eller andet med RAD tools i 00'erne. Tilbage i 90'erne havde man Access, VB6, Delphi og lidt mere eksotisk Jyacc (JAM & JPL). Men VB6 blev "erstattet" af VB.NET som reelt er noget helt andet, Delphi brugen styrtdykkede og Jyacc skiftede status fra eksotisk til uddød. Og selv Access som applikation er vel dykket i brug.
(jeg har lavet rigtigt meget Access, noget Jyacc, en lille smule Delphi og intet VB6)
WinForms, WPF, diverse Swing WYSIWYG editorer og divese web WYSIWYG editorer har aldrig nået samme niveau af nemhed.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund