mboost-dp1
#2
Hvornår har man nogensinde brug for goto? Jeg har ikke brugt den i 15 år og har ikke manglet den.
#topic
Ret spændende projekt de har gået i gang med. Hvis Google lægger lige så meget tanke og grundighed i projektet som deres andre projekter, skal det nok blive spændende at se hvad det bliver til.
Hvornår har man nogensinde brug for goto? Jeg har ikke brugt den i 15 år og har ikke manglet den.
#topic
Ret spændende projekt de har gået i gang med. Hvis Google lægger lige så meget tanke og grundighed i projektet som deres andre projekter, skal det nok blive spændende at se hvad det bliver til.
chreddy (1) skrev:Jeg er 100% overbevist om at newz.dk har skrevet forkert.. Det hedder da selvfølgeligt n00b (eller noob eller hvordan man nu vil skrive det).. :P
jeg grinte
Det er ikke et Google-project - det er et uafhængigt fritidsproject, der involverer programmører fra Google. (Google Code er åbent for alle).
Fra sitet:
"Who's behind Noop?
Noop is a side-project from a collection of like-minded developers and contributers. We hail from several companies, including (but not limited to) Google. "
Fra sitet:
"Who's behind Noop?
Noop is a side-project from a collection of like-minded developers and contributers. We hail from several companies, including (but not limited to) Google. "
#14 Sådan er/starter mange Google projekter jo, så vidt jeg ved da ;)
#13: Mike, lad nu være med at fordøm alt der ikke slutter på .NET eller starter med Microsoft...
Og jeg undrer mig lidt over navnet.. Vi laver et programmeringssprog, og kalder det selvfølgelig for "No Operation". En kommando som.. ja.. gør ingenting. :P
#13: Mike, lad nu være med at fordøm alt der ikke slutter på .NET eller starter med Microsoft...
Og jeg undrer mig lidt over navnet.. Vi laver et programmeringssprog, og kalder det selvfølgelig for "No Operation". En kommando som.. ja.. gør ingenting. :P
Der er sjældne tilfælde, hvor goto faktisk kan være den pæneste måde at implementere noget på. Jeg skrev f.eks. engang et program, hvor jeg havde brug for en endelig automat. Jeg endte med at implementere den del i assembler kode fordi det er så nemt at lave betingede goto instruktioner i assembler. Den resulterende kode blev pænere end hvis jeg havde gjort det i et højniveau sprog. (At lige netop den del af programmet var der hvor jeg havde brug for performance var et andet argument for at implementere det i assembler kode).
Men, hvis den slags når op i betydelige størrelser, så har man selvfølgelig brug for et højniveau sprog for generering af endelige automater (som f.eks. flex). Og CPUer er blevet ca. 50 gange hurtigere siden jeg skrev det program, så performance argumentet ville ikke være så væsentligt i dag.
Et andet eksempel hvor jeg har set mange goto kommandoer er i Linux, hvor det konsekvent bruges til fejlhåndtering. Det er dog ikke noget argument for at inkludere goto i et nyt sprog. Hvis man læser den brug af goto i Linux vil man se, at det er meget struktureret, der er bare ikke nogen sprogkonstruktion i C der dækker formålet. Så hvis man havde valget i et nyt sprog, så skulle man hellere lave en konstruktion, der er god til fejlhåndtering.
Det som Linux havde brug for er en konstruktion, der minder lidt om finally, men uden det komplicerede runtime environment der skal til for at lave fuld exception handling.
Faktisk kunne man tage det et skridt videre og prøve at designe sproget, så koden til fejlhåndtering i større grad kan autogenereres fremfor at skulle implementeres manuelt. Fejlhåndteringskode indholder nemlig et uforholdsmæssigt stort antal fejl. Det er tit man kommer til at glemme at frigive en eller anden resource, og så har man et memory leak i sin kerne.
Men, hvis den slags når op i betydelige størrelser, så har man selvfølgelig brug for et højniveau sprog for generering af endelige automater (som f.eks. flex). Og CPUer er blevet ca. 50 gange hurtigere siden jeg skrev det program, så performance argumentet ville ikke være så væsentligt i dag.
Et andet eksempel hvor jeg har set mange goto kommandoer er i Linux, hvor det konsekvent bruges til fejlhåndtering. Det er dog ikke noget argument for at inkludere goto i et nyt sprog. Hvis man læser den brug af goto i Linux vil man se, at det er meget struktureret, der er bare ikke nogen sprogkonstruktion i C der dækker formålet. Så hvis man havde valget i et nyt sprog, så skulle man hellere lave en konstruktion, der er god til fejlhåndtering.
Det som Linux havde brug for er en konstruktion, der minder lidt om finally, men uden det komplicerede runtime environment der skal til for at lave fuld exception handling.
Faktisk kunne man tage det et skridt videre og prøve at designe sproget, så koden til fejlhåndtering i større grad kan autogenereres fremfor at skulle implementeres manuelt. Fejlhåndteringskode indholder nemlig et uforholdsmæssigt stort antal fejl. Det er tit man kommer til at glemme at frigive en eller anden resource, og så har man et memory leak i sin kerne.
kasperd (19) skrev:Der er sjældne tilfælde, hvor goto faktisk kan være den pæneste måde at implementere noget på.
Jeg vil gerne se et konkret eksempel på det. Jeg vil nemlig gerne prøve at omsætte det til OO.
kasperd (19) skrev:Et andet eksempel hvor jeg har set mange goto kommandoer er i Linux, hvor det konsekvent bruges til fejlhåndtering.
Mener du i kernen? Jeg er nemlig ikke stødt på det i operativsystemet Linux.
#19 En endelig automat kan implementeres ganske pænt og effektivt med halekald.
Jeg synes ikke Noop ser særligt lovende ud. Det virker mere som en samling af "hippe" ideer end et egentligt design. De enkelte ideer virker ikke særligt gennemtænkte.
"Strong typing" - det er et meningsløst ord som er blevet synonym for "the sort of thing that works just how I like it". Når et sprog har et typesystem bliver det en af de vigtigste komponenter, da typesystemet ellers ender med at kæmpe imod programmøren.
I det hele taget virker det som om det er inspireret af COBOL, der ligeledes definerer snesevis af indbyggede keywords til alle mulige specifikke formål, istedet for at gøre det muligt for programmøren at løse disse opgaver selv.
Måske er det bare lækket lidt for tidligt.
Jeg synes ikke Noop ser særligt lovende ud. Det virker mere som en samling af "hippe" ideer end et egentligt design. De enkelte ideer virker ikke særligt gennemtænkte.
"Strong typing" - det er et meningsløst ord som er blevet synonym for "the sort of thing that works just how I like it". Når et sprog har et typesystem bliver det en af de vigtigste komponenter, da typesystemet ellers ender med at kæmpe imod programmøren.
I det hele taget virker det som om det er inspireret af COBOL, der ligeledes definerer snesevis af indbyggede keywords til alle mulige specifikke formål, istedet for at gøre det muligt for programmøren at løse disse opgaver selv.
Måske er det bare lækket lidt for tidligt.
Lige saa snart jeg hoerer "Noop bygger på Java Virtual Machine ..." taenker jeg kun, aaarh nej, saa skal der installeres Java version 300.2.3.51.13.4 og skal liiige patches med den og den og den fil, saa lige huske at .... gab, jeg holder mig til php ;) Det lyder ikke til noget jeg vil bruge endnu.
Java, Scala, Ruby, IDE's ... zzz
PHP -> done.
Java, Scala, Ruby, IDE's ... zzz
PHP -> done.
http://kerneltrap.org/node/553/2131
Goto giver fint mening i linux kernen og med den veldefinierede brug af goto. Problemet med goto er jo at man let kan lave spaghetti kode ved at smide gotos ind hvor en anden løsning ville være bedre, men som Linus skriver i LKML posten linket ovenfor, så er det lidt hjernevask at goto er totalt giftig, helt sikkert typisk Djikstra - som elskede at trolle computer scientists :).
Goto giver fint mening i linux kernen og med den veldefinierede brug af goto. Problemet med goto er jo at man let kan lave spaghetti kode ved at smide gotos ind hvor en anden løsning ville være bedre, men som Linus skriver i LKML posten linket ovenfor, så er det lidt hjernevask at goto er totalt giftig, helt sikkert typisk Djikstra - som elskede at trolle computer scientists :).
#24
Og Linus vælger specifikt ikke at svare på om det givne stykke kode uden GOTO ville være bedre. Hvilket den faktisk er.
goto bruges i Linux kernen, fordi at C ikke har et bedre system til fejlhåndtering. Og personligt synes jeg ikke det er en synderlig god løsning.
Men det er nu også ret typisk for Linus, at påstå at alle andre er hjernevasket, og det kun er hans egen lille drømmeverden som er effektiv.
Prøv at læs hans meninger omkring OOP. Hvis han nogen sinde skulle lavet andet end kernel hacking, ville han ende op med super horribelt kode, det er helt sikkert.
Anyways, point er virkelig at der ikke er nogen grund til at have goto i et nyt sprog. Exceptions er en meget bedre løsning til fejlhåndtering, og derfor dør den eneste grund til at have goto.
Og Linus vælger specifikt ikke at svare på om det givne stykke kode uden GOTO ville være bedre. Hvilket den faktisk er.
goto bruges i Linux kernen, fordi at C ikke har et bedre system til fejlhåndtering. Og personligt synes jeg ikke det er en synderlig god løsning.
Men det er nu også ret typisk for Linus, at påstå at alle andre er hjernevasket, og det kun er hans egen lille drømmeverden som er effektiv.
Prøv at læs hans meninger omkring OOP. Hvis han nogen sinde skulle lavet andet end kernel hacking, ville han ende op med super horribelt kode, det er helt sikkert.
Anyways, point er virkelig at der ikke er nogen grund til at have goto i et nyt sprog. Exceptions er en meget bedre løsning til fejlhåndtering, og derfor dør den eneste grund til at have goto.
Faktisk kunne man tage det et skridt videre og prøve at designe sproget, så koden til fejlhåndtering i større grad kan autogenereres fremfor at skulle implementeres manuelt.Den slags findes sådan set allerede i C# og det kommer til Java i næste version.
Goto giver fint mening i linux kernen og med den veldefinierede brug af goto.Grunden til at goto giver mening i Linux kernen er at C er et meget primitivt sprog som ikke understøtter rigtig fejlhåndtering. Det gør alle moderne sprog, og i dem hører goto ikke til.
En endelig automat kan implementeres ganske pænt og effektivt med halekald.Halekald er på ingen måde effektivt i C (eller et mange andre prodedurale sprog for den sags skyld).
"Strong typing" - det er et meningsløst ord som er blevet synonym for "the sort of thing that works just how I like it".Strong typing betyder at alle objekter har en type, og det betyder at den type ikke kan ændres uden at programmøren specifikt gør det. Det er et meget veldefineret ord...
Hmm, sært.kilde skrev:Noop says No to: Implementation inheritance (subclassing)
Assembly pænere end state pattern i et OO sprog?kasperd (19) skrev:Der er sjældne tilfælde, hvor goto faktisk kan være den pæneste måde at implementere noget på. Jeg skrev f.eks. engang et program, hvor jeg havde brug for en endelig automat. Jeg endte med at implementere den del i assembler kode fordi det er så nemt at lave betingede goto instruktioner i assembler. Den resulterende kode blev pænere end hvis jeg havde gjort det i et højniveau sprog.
Derudover ville sådan noget kode jo kræve en næsten total omskrivning hvis der opstod ændringer i dine states.
Moderne programmering handler mere om at skrive kode der er letlæselig, og nemt kan genbruges. Et hvilket som helst stykke kode med goto er næsten umuligt at genbruge.
Sprog som NOOP synes jeg er at tilbageskridt, men heldigvis er det jo ikke mere end et niche sprog lavet af en folk akademikere.
Jeg ville nok kigge på Haskell istedet for NOOP, hvis du er til den slags :)jakobdam (16) skrev:Interessant, og foreløbigt ser det da vildt lovende ud - især for mindre programmeringsopgaver. Eneste minus jeg tror der måske kan være, er skalerbarheden - men det må tiden jo vise.
Nu giver OOP jo ikke ret meget mening i en kernel. Derfor har Linus ret, han udtaler sig bevidst ikke om hvad der giver mening i userland hvor du sagtens kan bruge højere level ting der er lettere at læse.
Når du compiler, ender koden med at se identisk ud anyways på maskinkode niveau/assembler niveau. Der er masser af jz/jnz/jne/je/jmp label.. Se selv med gcc -S. Han påpeger endda at det kode eksempel der gives ikke nødvendigtvist er et sted hvor goto giver mening, men at der er steder hvor visse cleanups skal se i en hvis rækkefølge hvor escape med goto cleanup2, etc. er pænere.
Hvis man aldrig har programmeret i andet end C# og Java og andet kan jeg godt forstå man har så snævert synede holdninger men det er ved at være gammelt at hver eneste gang der er en diskussion om noget der ikke er .NET farer du ind og plaprer løst on noget som du tydetligtvist ikke har mere end overfladisk forstand på.
Når du compiler, ender koden med at se identisk ud anyways på maskinkode niveau/assembler niveau. Der er masser af jz/jnz/jne/je/jmp label.. Se selv med gcc -S. Han påpeger endda at det kode eksempel der gives ikke nødvendigtvist er et sted hvor goto giver mening, men at der er steder hvor visse cleanups skal se i en hvis rækkefølge hvor escape med goto cleanup2, etc. er pænere.
Hvis man aldrig har programmeret i andet end C# og Java og andet kan jeg godt forstå man har så snævert synede holdninger men det er ved at være gammelt at hver eneste gang der er en diskussion om noget der ikke er .NET farer du ind og plaprer løst on noget som du tydetligtvist ikke har mere end overfladisk forstand på.
Hvis du havde læst indlæget, gav jeg bare udtryk for at Linus har en meget speciel holdning til visse koncepter/teknikker inden for programmering. Så man bør tage hans meninger med et gran salt.decx (30) skrev:Nu giver OOP jo ikke ret meget mening i en kernel.
Det er jo så et spørgsmål om meninger. Der er forskellige måder at implementere løsningerne på, goto er kun een af dem.decx (30) skrev:men at der er steder hvor visse cleanups skal se i en hvis rækkefølge hvor escape med goto cleanup2, etc. er pænere.
Hvis man arbejder ud fra udgangspunket at goto slet ikke bør bruges, så vil det heller aldrig føles nødvendigt at bruge det.
Hvilket man aldrig har lavet andet en lowlevel hacking i C, kan man også godt forstå at man har så svært ved at fatte højniveau koncepter.decx (30) skrev:Hvis man aldrig har programmeret i andet end C# og Java og andet kan jeg godt forstå man har så snævert synede holdninger
Hvor mange sprog har DU kodet i?
Hvis du tager nogle af de gode eksempler i Linux, så kan du sikkert omsætte dem til OO. Men hvad vil du gøre, når det samtidig er et krav, at det skal kunne køre i samme runtime environment som C kode? Det er stort set kun C og assembler kode som kan køre under de forudsætninger. De OO sprog jeg kender til kræver alle et større runtime environment.myplacedk (21) skrev:Jeg vil gerne se et konkret eksempel på det. Jeg vil nemlig gerne prøve at omsætte det til OO.
Her er et lille udsnit af det tilfælde jeg nævnte tidligere, hvor jeg havde brug for så mange gotos, at jeg endte med at skrive det i assembler:
TRANS MACRO x,y
CMP AL,8*x
JZ y
ENDM
;*************
;** FA code **
;*************
Start: XOR DI,DI
JMP W
W1: CALL GET
TRANS 2,Start
TRANS 4,S0
TRANS 8,S2
TRANS 16,S5
JMP I
W2: CALL GET
TRANS 1,Start
TRANS 4,S1
TRANS 8,S3
TRANS 16,S6
JMP I
Der er i alt 16 tilstande og 39 transitioner mellem tilstandene. Den komplette kode er her: http://kasperd.net/~kasperd/FA.ASM
Hvordan ville I implementere det samme struktureret uden brug af goto statements?
Mener du i kernen? Jeg er nemlig ikke stødt på det i operativsystemet Linux.Ja, jeg mener kernen. (Linux er navnet på en kerne. Kombinationen af Linux og ovenliggende software bliver ofte blot kaldt Linux, men det er ikke en helt korrekt betegnelse. Da jeg sagde Linux mente jeg Linux.)
Det eksempel der gives er så et tilfælde, hvor brugen af goto er gået lidt for langt. En simpel if blok havde været bedre i det tilfælde.decx (24) skrev:http://kerneltrap.org/node/553/2131
Goto giver fint mening i linux kernen og med den veldefinierede brug af goto.
Her er et eksempel på noget kerne kode jeg engang skrev uden brug af goto statements: http://kasperd.net/~kasperd/linux_kernel/kcp.c
Resultatet er så syv niveauer af nestede if statements. Det er hverken kønt med de mange goto statements eller med nestede if statements.
Begge sprog stiller større krav til runtime environment end C. Jeg mente, at det ville være smart, hvis der kunne genereres kode, som var selfcontained og ikke stillede den slags krav til runtime environment som C # og Java gør.mathiass (26) skrev:Den slags findes sådan set allerede i C# og det kommer til Java i næste version.
kasperd (32) skrev:Hvis du tager nogle af de gode eksempler i Linux, så kan du sikkert omsætte dem til OO. Men hvad vil du gøre, når det samtidig er et krav, at det skal kunne køre i samme runtime environment som C kode?
Så er det ikke længere et spørgsmål om hvorvidt "goto" er pænere end "OO".
kasperd (32) skrev:Her er et lille udsnit af det tilfælde jeg nævnte tidligere, hvor jeg havde brug for så mange gotos, at jeg endte med at skrive det i assembler
Hm. Jeg skal vist lige have læst lidt om assembler for at fatte det der. :-D
Hvad ligger der i vejen for at implementere det funktionelt, bygget ud fra et generelt State Pattern?kasperd (32) skrev:Hvordan ville I implementere det samme struktureret uden brug af goto statements?
Jeg kan ikke rigtig forstå pointen i at bruge goto, når sproget i sig selv ikke kræver goto for at kalde subrutiner (som det ellers er tilfældet i COBOL).
Jeg tænkte på using-konstruktionen (MSDN). Omkring sådan en genereres automatisk en passende oprydning af objektet (også på de exception edges hvor man plejer at glemme det).Windcape (27) skrev:Hvad tænker du på her?
Begge sprog stiller større krav til runtime environment end C. Jeg mente, at det ville være smart, hvis der kunne genereres kode, som var selfcontained og ikke stillede den slags krav til runtime environment som C # og Java gør.Du har ret i at Java og C# som udgangspunkt kræver mere af runtime environment end C, men using konstruktionen garanterer bare at en oprydningsrutine bliver kaldt når en variabel går ud af scope. Det er rent compilerarbejde.
#32: Jeg tror at det er et bedre eksempel på at "når man har en hammer så ligner alting et søm" end det er et godt eksempel på at goto er uundværligt. Jeg har implementeret FA'er i Java og det kan gøre ganske simpelt og ligetil. Java har en mulighed for at sætte labels på loops som kan bruges i forbindelse med break og continue. Det er sådan set et rigtig godt redskab til at implementere tilstandsmaskiner, men jeg har aldrig brugt det til andet. Det er nok også derfor de ikke puttede det i C#.
Her bliver jeg så lige nødt til at rette på mig selv, for strengt taget var det ikke OO jeg tænkte på, men exception handling. Der er så bare en tendens til at det er de samme sprog, der har OO og som har exception handling. Den eneste undtagelse, jeg lige kunne komme i tanke om, er Turbo Pascal, der havde OO men ikke exception handling.kasperd (32) skrev:Hvis du tager nogle af de gode eksempler i Linux, så kan du sikkert omsætte dem til OO.
I de eksempler jeg refererede til er der brug for at resourcerne frigives i tilfælde af en fejl, men hvis kaldet ikke fejler overtager kalderen alle de allokerede resourcer.mathiass (35) skrev:Jeg tænkte på using-konstruktionen (MSDN). Omkring sådan en genereres automatisk en passende oprydning af objektet (også på de exception edges hvor man plejer at glemme det).
Du har ret i at Java og C# som udgangspunkt kræver mere af runtime environment end C, men using konstruktionen garanterer bare at en oprydningsrutine bliver kaldt når en variabel går ud af scope. Det er rent compilerarbejde.Den artikel du linkede til får det mest af alt til at lyde som en workaround for tilfælde, hvor garabage collection deallocerer ting senere end man ønskede sig.
#32: Jeg tror at det er et bedre eksempel på at "når man har en hammer så ligner alting et søm" end det er et godt eksempel på at goto er uundværligt. Jeg har implementeret FA'er i Java og det kan gøre ganske simpelt og ligetil.Kan du vise et eksempel på hvordan det ser ud.
Java har en mulighed for at sætte labels på loops som kan bruges i forbindelse med break og continue. Det er sådan set et rigtig godt redskab til at implementere tilstandsmaskiner, men jeg har aldrig brugt det til andet.Jeg kan ikke forestille mig, hvordan det kunne bruges til en tilstandsmaskine.
Mit konkrete eksempel havde så tilfældigvis også brug for at tilgå en I/O port, hvilket man mig bekendt ikke kan i Java, så Java havde ikke været en mulighed. Og Java giver vel heller ikke nogle realtime garantier. (Det ville også være nødvendigt, når nu man skal læse en værdi fra en I/O port, der ændrer sig hvert 25. ms.)
Men hvis du kan demonstrere, hvordan en tilstandsmaskine kan implementeres pænt i Java, så skal jeg da gerne ændre mit udsagn.
Using bruges faktisk mere til at sikre at f.eks. Close() bliver kaldt på en stream, efter brug.kasperd (37) skrev:Den artikel du linkede til får det mest af alt til at lyde som en workaround for tilfælde, hvor garabage collection deallocerer ting senere end man ønskede sig.
Det er bare scoping med automatisk kald til en metode når koden er færdig i det givne scope.
kasperd (37) skrev:Den artikel du linkede til får det mest af alt til at lyde som en workaround for tilfælde, hvor garabage collection deallocerer ting senere end man ønskede sig.
using/Dispose er ikke til deallokering af managed resourcer (som memory der GC'es) med til deallokering af unmanaged resourcer (typisk fil/net/database forbindelser).
Det er reelt en short notation for et kald af Dispose i en finally block.
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
- ⟨
- Nyheder
Gå til bund