Python noob - forskjell på rekursiv og non-rekursiv funksjon

[kim009]

Han sa vel at han kun google det med å bruke egen assembly kode for timing av kode snutter i Python. Det virker som en rimelig tungvindt måte og gjøre noe lettvint på, noe som går imot hele hensikten med Python. I dette tilfellet hvor man skal sammenligne en rekursiv og iterativ sorterings algoritme så har det vel til og med lite å si om du bruker time eller clock i windows. Det er jo bare å kjøre den flere ganger over flere lister og dele på antallet, 16ms fra eller till har da lite å si (noe som forøvrig ikke ble gjort over. Det burde ha blitt gjort siden enkelte like lange lister kan variere en del på hvor lang tid det tar å sortere dem).

[LonelyMan]

han velger selv hva han vil gjøre, jeg foreslår bare løsninger, jeg foreslo å gi han et ferdig bibliotek for å måle meget nøyaktig og jeg foreslår å bruke en haug med varianter, der er mange å velge mellom.

 

Når det gjelder å laste inn assembly kode fra en dll så "virker det tungvint" for de som aldri har gjort det, men for oss som vet at det tar 1 linje i python å laste en dll så vet vi at det ikke er tungtvint.

 

Dette med google, det er andre gang Geir googler i denne tråden, jeg synes det blir mye googling vs deling av erfaringer.

 

Jeg mener, hva kommer først av høna og egget. Skal du si deg uenig før du googler?

Where is the credibility. Nei, som jeg sa, om du vet noe så del det gjerne, men om du ikke vet, så er dette et forum for diskusjon og deling av erfaringer, ikke et forum for å dele internett-søk. Om google søk er like verdifulle som erfaringer, hva skal man egentlig med erfaringer. Det er ikke uten grunn jeg må diskutere unødvendig med geirern, det er fordi han googler, tror på det han leser, og så blir han frustrert når hans googlinger møter erfaringer. Det ligger mye verdi i google, det har jeg ingenting imot, men det er poengløst hvis en ikke har erfaring med det til å begynne med, for det er alltid mer under enn det man leser.

 

Her er en type diskusjon som jeg ikke synes noe om:

 

Person A: Påstår X

Person B: X er dumt.

Person A: Forklarer hvorfor X ikke er dumt, og nevner i samme linje at Y kan være fordelaktig.

Person B: Jaja, X er jo sånn og sånn, men nå er det dumt å bruke Y

PersonA: Forklarer hvorfor Y ikke er dumt, og kommer inn på Z i samme kjør.

PersonB: Vel, jeg var for sen på jobb, skrev for fort angående Y, men nå er jo Z dumt.

PersonA: Forklarer hvorfor Z ikke er dumt, og kommer inn på T og hvorfor T også er bra

PersonB: Nå spiste jeg sur middag i går så jeg fikk ikke helt med meg hvorfor Z også er dumt, men nå er iallefall T dumt.

PersonA: Forklarer hvorfor T ikke er dumt og går videre til H.

PersonB: Kanskje ikke T er dumt, men H er iallefall dumt.

PersonA: Forklarer hvorfor H ikke er dumt og går videre til G.

PersonB: *Googler* en eller annen term eller definisjon for å flytte diskusjonen over på semantikk.

PersonA: Må bare følge med hvor diskusjonen bærer hen, den har hoppet fra månen til pluto allerede.

 

Denne typen diskusjon er tidsløsing. Dette er diskusjonens variant av spillet Tic Tac Toe. Man har ikke noe poeng før en tilfeldigvis lander på et poeng ved uhell. :nei2:

 

Kim009: Du kan lese 1,28 MB (på en gamlere datamaskin som jeg har) med data fra RAM på 1 millisekund, hva du kan gjøre på 16 millisekund er ikke mye for mennesker, men for en datamaskin er det en hel verden. det er ikke nitpicking, men mange undervurderer hvor raskt ting faktisk skjer.

Endret 13. januar 2013 av LonelyMan

[GeirGrusom]

Dette er et diskusjonsforum hvor vi diskuterer erfaringer, dette er ikke en extension for google hvor du får et spørsmål og så google opp et svar. Det er hele meningen med diskusjonsforum at man gir svar på det man kan, det er ikke slik at A: man får et spørsmål fra venstre side, B: Man strekker høyre hånden ut til google, søker etter svar, C: Legger ut svaret på forumet. Du har misforstått hele poenget med diskusjonsforum. Problemet når man skal diskutere gjennom google er at man da aldri kan være helt sikker på hva man snakker om. Om du vet noe, svar tilbake, om du ikke vet, så er det best å gå videre til neste tråd for da kan man aldri være helt sikker på hva man skriver, og jeg ser gang på gang at du ikke vet hva du snakker om. Jeg husker du var i assembler forumet og skulle gi hint om GetASyncKeyState, da måtte jeg korrektere deg kraftig og du hadde googlet det opp på msdn og lest halve artikkelen, men glemte å lese type defiinisjonen på funksjonen. Det er et godt eksempel på hvorfor google-diskusjoner ikke fungerer, kan du noe så skriv gjerne, må du google det opp så bare gå til neste tråd.

 

Det biblioteket mitt var bare et forslag for å få en noenlunde god tidsmåling i quicksort eksemplet vi brukte, ikke for å gjenbrukes, men nå har jeg faktisk skrevet det for å være portabelt mellom ganske mange plattformer så det går likevel an å gjenbruke det om det skulle vært et mål. Du tenker altfor prinsippielt og er ikke løsningsorientert.

 

Slik som når du skrev det dumme argumentet om at tidsmåling var irrelevant, så begrunner jeg klart og tydelig hvorfor det er relevant, så begrunner du det tilbake med at du er it konsulent, dette er dårlig argumentering.

Men du diskuterer ikke, du kommer med helt syke påfunn som du etterpå må rasjonalisere.

 

Programmer må skrives for å kjøre i user mode.

 

Ikke skriv objektorienterte spill.

 

Usammenhengdende tøv om pekere fra en som ikke ser ut til å forstå pekere i C.

 

Nedlatende tone, etterfulgt av manglende forståelse for grafikkprogrammering, og nok en ASM Win32 implementasjon i et annet programmeringsspråk selv når TS vil ha Linux støtte i C.

 

Vet ikke at kode som blir forkastet, gjør det av designårsaker, sjeldent på grunn av ytelse

eller programmeringsspråk.

 

Rekursjon er dårlig programmering

 

Jeg er egentlig temmelig lei av å diskutere med deg, men du kommer med helt fulsltendig ensidige uttalelser hele tiden i alle mulige tråder der det ikke hører hjemme. Jeg kunne også ønske meg at du for fremtiden kan holde deg ihvertfall til programmeringsspråket som diskuteres. Assembly er det et eget forum for, og i mange språk så er assembly uvesentlig, spesielt fordi de fleste språk kan kjøres på flere prosessorer enn bare x86 og andre operativsystem enn Windows. Nå ser også ARM ut til å bli mer og mer relevant.

 

Når det gjelder GetAsyncKeyState så er det et tåpelig argument. Jeg skrev feil i kommentaren, men jeg påpekte at du feilimplementerte GetAsyncKeyState fordi du brukte returverdien som en boolest verdi når det vitterlig er et bitfelt i følge dokumentasjonen. Feilen førte til latency på input (som du dedikerte 100% av en CPU-kjerne for å lese). Jeg påpekte en programmeringsfeil i en bedriten implementasjon.

Jeg kom hit for å påpeke at (som du også påpekte tidliger) diksujon om Assembly hører ikke til her. Win32 er også irrelevant, fordi det er Python det er snakk om. Timing er også egentlig irrelevant ettersom dette handler om rekursive algoritmer, og forslaget du kom med for å løse det var rett og slett feil svar.

 

Etterpå er det jo jeg som er teit fordi jeg skrev 16-bit hex istedet for 32-bit som det skulle vært for å løse din feilimplementasjon av GetAsyncKeyState.

Endret 14. januar 2013 av GeirGrusom

[kim009]

Når det gjelder å laste inn assembly kode fra en dll så "virker det tungvint" for de som aldri har gjort det, men for oss som vet at det tar 1 linje i python å laste en dll så vet vi at det ikke er tungtvint.

Tenkte mer att det virker tungvindt og gjøre koden avhengig av tilleggs biblioteker som kan være problematisk for andre og finne, eller om de skulle vise seg å være fastlåst til spesifikke plattformer, om Python har funksjoner som fint klarer å løse problemet selv uten nevneverdige ytelse tap.

 

 

Kim009: Du kan lese 1,28 MB (på en gamlere datamaskin som jeg har) med data fra RAM på 1 millisekund, hva du kan gjøre på 16 millisekund er ikke mye for mennesker, men for en datamaskin er det en hel verden. det er ikke nitpicking, men mange undervurderer hvor raskt ting faktisk skjer.

Klar over at en data kan gjøre mye på 16ms. Men i de fleste tilfellene som jeg snakket om så må man måle tiden over en rekke forskjellige start verdier og ta snittet for å finne tiden om man ønsker en fornuftig måling. Noen få algoritmer holder samme tid for hver posisjon med N elementer, men ganske mange, spesielt quick sort som er brukt her, kan varierer kraftig mellom de forskjellige start posisjonene.

[LonelyMan]

Men du diskuterer ikke, du kommer med helt syke påfunn som du etterpå må rasjonalisere.

 

Rasjonalisere for de som ikke forstår det ja, det er som regel kun deg jeg må rasjonalisere for.

 

Programmer må skrives for å kjøre i user mode.

 

Ikke skriv objektorienterte spill.

 

Usammenhengdende tøv om pekere fra en som ikke ser ut til å forstå pekere i C.

 

Nedlatende tone, etterfulgt av manglende forståelse for grafikkprogrammering, og nok en ASM Win32 implementasjon i et annet programmeringsspråk selv når TS vil ha Linux støtte i C.

 

Vet ikke at kode som blir forkastet, gjør det av designårsaker, sjeldent på grunn av ytelse

eller programmeringsspråk.

 

Rekursjon er dårlig programmering

 

Nå hopper du videre å forsøker å komplisere tråden med helt vidt nye innlegg, hva slags diskusjon skal du holde ved å linke til halve forumet? Det du linker til er ikke tøv, neste gang får du ta en ting om gangen og ikke linke til tråder og tro du kan vinne argumenter ved å linke til de uten noen argumenter i det hele tatt. Diskuter i de trådene det gjelder, og så holder du deg on topic i denne tråden.

 

Når det gjelder GetAsyncKeyState så er det et tåpelig argument. Jeg skrev feil i kommentaren, men jeg påpekte at du feilimplementerte GetAsyncKeyState fordi du brukte returverdien som en boolest verdi når det vitterlig er et bitfelt i følge dokumentasjonen.

 

Punkt 1: Man skriver ikke erfaringsmessig feil, du hadde lest noe og siterte hukommelsesmessig feil. Hadde du engang hatt erfaring i å bruke GetASyncKeyState før så ville du ikke glemt hvordan man brukte den. Man glemmer som regel kun ting man ikke er kjent med.

 

Når det gjelder returverdi som bool, så må du sitere meg på den, det er mulig du har lest asm koden feil, der er mange triks man benytter i asm som kan se ut som noe skjer feil, det er fordi når man programmerer i asm så manipulerer man ting ofte, en programmerer manipulerer, der er ingen standarder. Så du må gjerne sitere hva du mener.

 

Win32 er også irrelevant, fordi det er Python det er snakk om.

 

Selv om dette er veldig utenfor konteksten (da jeg forklarte tydelig at jeg kom med et forslag blant mange forslag til han) Halve verden bruker fortsatt win32, win64 wow støtter fortsatt kjøring av win32, og win32 programmer er fortsatt mest teknisk effektive og vil være det i lang tid fremover, Programmer som kjører krever fortsatt lite ram (med unntak av spill) og programmessig vil win32 fortsatt være evig nok for programmer. Du vet rett og slett ikke hva du snakker om her, python er designet for å kjøre på mange plattformer, og win32 er en sterk kandidat av dem.

 

Timing er også egentlig irrelevant ettersom dette handler om rekursive algoritmer, og forslaget du kom med for å løse det var rett og slett feil svar.

 

Det handler ikke bare om rekursive algoritmer, det handler om "forskjell på rekursiv og non-rekursiv funksjon", må du lese trådemne før du påstår noe. Dette innebærer diskusjon om rekursive og iterative funksjoner. Jeg er helt on topic. "Forskjell mellom rekursiv og non-rekursiv funksjon" innebærer diskusjon om rekursjon og iterative funksjoner.

 

Hvilke forslag? Jeg beskrev tekniske utfordringer rekursive funksjoner har som iterative funksjoner ikke nødvendigvis har og jeg står fortsatt fast på det, om du vil diskutere de tekniske punktene jeg la frem så må du si ifra, for da er jeg klar til å diskutere det igjen. Jeg har fortsatt ikke fått noen tilbakemeldinger på disse tekniske utfordringene.

 

Etterpå er det jo jeg som er teit fordi jeg skrev 16-bit hex istedet for 32-bit som det skulle vært for å løse din feilimplementasjon av GetAsyncKeyState.

 

Der er ingen feilimplementasjon, du har lest feil der, akkurat som du leste msdn dokumentasjonen feil, så har du lest feil 2 ganger på rad og nå påstår du at du ikke leste feil som gjør at du tar feil en tredje gang.

 

Hvor mange feile påstander du vil ende opp i sum er det bare du som bestemmer. Men jeg gjentar meg selv, jeg har ikke implementert GetASyncKeyState feil, så jeg foreslår at du glemmer hele den greia, eller så foreslår jeg at du tar det opp i asm forumet, dette er python forumet som du så fint sa til meg tidligere at asm ikke hører hjemme her.

 

Nå har du hoppet fra pluto til alpha centauri ang hovedpoenget ditt.

Endret 14. januar 2013 av LonelyMan

[LonelyMan]

jeg påpekte at du feilimplementerte GetAsyncKeyState fordi du brukte returverdien som en boolest verdi når det vitterlig er et bitfelt i følge dokumentasjonen.

 

Ja det er et bitfelt og du har lest feil her også. Om det hadde vært at jeg tolket den som en bool så ville koden sett slik ut:

 

test eax,eax

 

Men min kode ser slik ut:

 

test eax,ebx
jnz @F

 

merk deg at det står eax,ebx, ikke eax,eax, og ebx er $8000 som gjør at en beholder h.o biten som sjekker om tasten er nede eller ikke. L.O biten skal ikke brukes den er bare for å ha det bakoverkompatibelt og den er høyst usikker.

 

msdn: "and if the least significant bit is set, the key was pressed after the previous call to GetAsyncKeyState. However, you should not rely on this last behavior; for more information, see the Remarks."

 

Da er det bare en bit igjen man kan stole på, teknisk sett er der flere, men jeg sletter de irrelevante bitene, og ja det blir på en måte en bool da, men problemet her er at du kaller det bitfelt, teknisk sett etter de "farlige" bitene er fjernet er det bare en bit igjen å bruke, da kaller du dette en bool.

 

Men det er ikke en bool, boolske verdier har L.O bit satt, ikke H.O bit satt.

 

Jeg er helt og 100% korrekt her, som jeg som regel er når jeg diskuterer, så jeg liker dårlig at du diskuterer ting du åpenbart ikke forstår, og det er dønn ærlig. Det samme gjelder de andre trådene du linket til.

 

Hva skal man gjøre med diskutanter som 2-3 og i fjerde ledd påstår at implementasjon er feil, selv når den er 100% korrekt og mot debattanten ikke bare foreslår feil implementering, men foreslår at den opprinnelige implementasjonen er feil når den så absolutt og helt og holdent ikke er feil implementert. Hva skal man gjøre med slike folk, skal man bare overse de, kom gjerne med forslag, for jeg vet ikke hva jeg skal gjøre med geirern.

 

Geirern:

 

Punkt 1: Implementasjonen min er korrekt.

Punkt 2: Den tolkes ikke som bool.

Punkt 3: Om den hadde vært tolket som bool ville jeg brukt bit 0, ikke bit 15

Punkt 4: Jeg sletter alle biter unntatt bit 15, det er ikke å tolke som bool, det er del av en prosess for å nettopp unngå tolking som bool

Punkt 5: Du foreslo en feilimplementering av GetASyncKeyState

Punkt 6: Jeg sier du kom med feilimplementering

Punkt 7: Du nekter fortsatt!?!?!?! og i tillegg fortsatt står fast på at jeg feilimplementerte den

 

Skal du holde deg on topic her eller skal du hoppe til et nytt tema?

Endret 14. januar 2013 av LonelyMan

[GeirGrusom]

tråden er vel ferdig diskutert ettersom det første innlegget som tomsi42 la inn løste saken greit. Deretter kommer du med det merkelige utsagnet om at rekursive funksjoner er dårlig programmering, og sporet diskusjoner over på tull og tøys derifra.

[etse]

Må bare nevne at denne "Better than though" holdningen som blir vist av enkelte her er nesten kvalmende, og bidrar absolutt ikke til tråden. Om man skal klare å kjøre noen form for diskusjon må man først tørre å inrømme for seg selv at man faktisk ikke er perfekt eller noe bedre enn andre; og at man av og til kan ta feil. Og komme med kommentarer som at "Jeg vet jeg alltid har rett når jeg diskuterer" blir litt merkelig, med tanke på at vi alle er mennesker - og mennesker gjør feil.

 

Det å så kritisere andre og å si de er kunskapskløse eller ikke har kompetanse blir litt merkelig, og er meget dårlig retorikk. Det gjør også veldig lite annet enn å direkte provosere motdebatanten. Hvem er du til å si at du er så mye bedre enn de andre i denne tråden? Bare fordi man er en person som hovedsaklig programmerer assembly så gjør det deg ikke til en bedre utvikler. Det kommer tydelig frem av mange innlegg i tråden at denne kompetansen og "inservringa" mot assembly har vært med på å gi deg et litt snevert syn på hvordan utvikling fungerer i industrien i dag - og jeg har flere ganger sett Geir prøve å påpeke dette til deg - men du vil aldri ta til deg kritikken.

 

Det er ikke i alle tråder når man diskuterer algoritmer at det er veldig relevant å fokusere på om den ene koden er noen millisekunder raskere enn den andre koden - da det aldri var noe poeng i å spare disse millisekundene.

 

Det blir og merkelig å kommentere at rekursive funksjoner er dårlige, da de kun er dårlige om man er i en kontekst hvor bakdelene ved rekursjon faktisk er relevante. Rekursjon gir ofte lettleselig kode, og mange algoritmer er ofte mye lettere å skrive rekursivt enn iterativt. Jeg ser da ikke noe poeng i å kaste bort masse tid på å prøve å finne en god måte å skrive den iterativt, om den rekursive fungerer bra nok.

 

Jeg vil legge ved at noen det første jeg fikk høre når jeg spurte en som jobber med rekruttering om hva den største utfordringen var med nyutdannede utviklere så fikk jeg til svar "Nyutdannede utviklere har ikke helt forståelsen med begrepet bra nok. De leiter etter den beste løsningen på problemet - noe som gjerne tar lengre tid og i praksis ikke gir noen avkastning." Selv om man kan skrive en algoritme bedre iterativt, er den rekursive ofte god nok.

Endret 14. januar 2013 av etse

[LonelyMan]

Jeg vil legge ved at noen det første jeg fikk høre når jeg spurte en som jobber med rekruttering om hva den største utfordringen var med nyutdannede utviklere så fikk jeg til svar "Nyutdannede utviklere har ikke helt forståelsen med begrepet bra nok.

 

Enig her, men det er en vesentlig forskjell på å "lete etter det beste" og det å implementere det en allerede vet uten å sløse vekk noe tid.

 

Lett å bli forvirra her, mange antar at å finne det beste handler om å søke seg ihjel eller skrive seg ihjel, nei, det handler om erfaring, dvs. du implementerer det du vet er best fra din egen erfaring.

 

Ja, om du er nybegynner så ikke sløs vekk tiden, om du er erfaren og allerede vet hvordan ting blir best mulig, så implementer det best mulig, enkelt og greit.

 

Det kan sammenliknes med en gullgraver, ikke sløs vekk tiden på å lete etter 1 kvadratcentimeter gullklump når du allerede vet hvor du kan finne 1 kvadratmeter gullklump.

 

big difference

 

Per velger den mindre attraktive løsningen, for han vet ikke om den andre.

Pål vet om den mindre attraktive løsningen og en bedre, og velger den beste han vet.

 

etse: Det å "sløse vekk tid" er ikke å sløse vekk tid, det er et annet ordtak for "studere". Du sløser ikke vekk tid på å lete etter noe du ikke vet om, det kalles som sagt å studere, kan du ikke en ting så kan du ikke en ting, da sløser du ikke vekk tid på noe du kan, men noe som du egentlig burde ha studert tidligere. Sagt på en annen måte: Om du bestemmer deg for å delta i rally, så vil det være tidsløsing for deg å forsøke å vinne i rally når du ikke er en rallyfører. hehe

 

SELVFØLGELIG er det tidsløsing å forsøke å lage en god kode om du ikke vet hva god kode er. Det mangler studering.

 

Men her er en ting som blir feil å si: "Det er tidsløsing å lage god kode"

Spesielt blir det feil å si når en i prinsipp ikke vet hva god kode er, fordi en prinsippielt ikke har sløst vekk tid på å lære hva god kode er. Det blir litt som å si til Martin Schanche at "det er tidsløsing å vinne i rally, følg heller oss som taper i rally, å få til det nest beste er standard i rally"

 

Om en person klarer å overbevise deg om at du burde spise en råtten potet istedet for en fersk, så må du inrømme at han er genial.

 

En annen type eksempel er: Det er dårlig å bruke mye tid på å kode på den måten fordi det blir lite penger av det å kode på den måten. (Problemet her er at god programmering ikke har noen verdens ting med penger å gjøre, om det er ønskelig å diskutere hvordan man fortest mulig kan tjene penger, så kan vi heller diskutere lotto eller gambling, men så lenge vi snakker om GOD programmering, så er økonomi fullstendig irrelevant)

 

Person X: Jeg tjener 10 kroner mer i uka, derfor er din type programmering dårlig.

Person Y: Nei, 10 kroner ekstra i uka er ikke et godt argument for hva god koding er.

Person X: Jo, sjefen min sa det.

Person Y: Sjefen din er økonom, og du er hans student. Jeg snakker om programmering her, ikke økonomi.

 

Person A: Jeg tjener 100 kr mer i uka, derfor er din måte å utnytte stacken på dårlig.

Person B: Nei, 100 kr ekstra i uka har ingen teknisk verdi ang. stacken.

Person A: Jeg kan spise 10 ekstra bananer i matpausen fordi min koding tar kortere tid, derfor er din høyt optimaliserte kode dårlig.

Person B: Nei, 10 ekstra bananer er ikke et godt argument for hvorfor høyt optimalisert kode er dårlig.

Person A: Jeg kjører en BMW som jeg har spart opp ved hjelp av å kode veldig flatt, du kjører en Mazda fordi du forsøker å lage god kode, derfor er din kode dårlig

Person B: Din BMW er ikke et godt argument for at min kode er dårlig, din BMW er et godt argument for at du har en god BMW.

Person A: Jeg har 200 tusen på sparekontoen min, da kan din kode umulig være bedre enn min.

Person B: Nei, 200 tusen kroner på sparekontoen er ikke et teknisk argument for at du har laget god kode.

Person A: Jo Martin sa det i matpausen.

Person B: Martin burde sparkes.

Person A: Hvorfor har jeg da lurt meg selv til å tro at raske penger har alt å gjøre med god programmering?

Person B: Fordi alle gjør det, alle tror at penger tjent er best programmering, men sannheten er at god kode er god valuta for en datamaskin, ikke for bankkontoen din. Det er kun datamaskinen som tjener på god kode, ikke bankkontoen.

Person A: Om jeg lager 70% god kode og tjener 110% på det, kan jeg da skryte til en annen at min kode er bedre om hans kode er 98% god og inntekten er 60%?

Person B: Nei, da kan du skryte at du har bedre inntekt og dårligere kode, hvilket gjør deg til en dårligere programmerer og en bedre forretningsmann.

Person A: Så min forretningssans har ingen teknisk verdi hva angår programmering?

Person B: Nei.

Person A: Så om vi snakker ren programmering, så er min kode dårligere, men mer forretningsmessig fornuftig?

Person B: Riktig. Ingen teknisk verdi for programmering, og stor verdi for din økonomi.

Person A: Hva er et programmeringsforum forresten?

Person B: Det er et forum for å diskutere programmering. Men det er stor forretningsmessig sans her inne også som kan gå på bekostning av de som er teknisk interesserte.

 

 

Ble mange artige sammenlikninger her, men you get the point hopefully.

Endret 14. januar 2013 av LonelyMan

[etse]

Er viktig er man først definierer litt hva man legger i ordene, så man ikke snakker rundt seg. Altså hva man legger i sløsing - og hva som er god kode.

 

Når jeg snakker om sløsing, så kan man jo si at så lenge man tilegner seg ny kunskap så er det ikke direkte sløsing. Men jeg tenker mer i sammenheng, kan du forsvare det økonomisk den tiden du brukte på å lære det du måtte lære for å få til den bedre løsningen? Svaret på det kommer jo ann på hvor stor forbedringen er - og om forbedringen er forbedringer av ting som er relevant.

 

La oss ta eksempel hvor du skal skrive en algoritme som sorterer en mengde data. Du kjenner til et par sorteringsalgoritmer som du kan bruke til å løse oppgaven, og implemneterer en av disse relativt fort. Denne vil da alltid kunne holde din data sortert.

 

Alternativt kunne du brukt litt tid først på å finne en bedre og raskere sorteringsalgoritme. Dette vil selvfølgelig bety at sorteringen vil gå fortere og at du bruker mindre dataressurser på sorteringen. Men er dette noe som virkelig betyr noe? - Dette kan man jo kun svare op om man kjenner det bestemte scenarioet. I enkelte tilfeller vil denne økte ytelsen være god fordel - i mange andre tilfeller er den rett og slett ubetydelig.

 

Det og et spørsmål hva man legger i god kode. Når jeg snakker om god kode er det ofte i kontekst av ryddig kode som er lett å forstå, vedlikeholde og eventuelt utvide ved behov - selv for en tredjepart. Samt at koden skal gi riktig resultat og driftsikker. Ytelse er veldig sjeldent i fokus - da vi pleier å ha mer enn nok datakraft tilgjengelig så det gjør opp for at koden er langt i fra optimalisert.

 

Edit: Rally-eksempelet ditt var dog noe merkelig. Ser ikke helt hva det har med hverdagen til en vanlig utvikler å gjøre. Det er ikke noe behov for å levere den beste løsningen direkte. Man er ute ettere å levere den beste komplette pakken; det vil si et produkt som dekker behovene til kunden for lavest mulig pris. Det helper ikke om konkurenten har et bedre produkt, om de samtidig må bruke betydelig mye mer tid på å utvikle den. (og dermed er prisen høyere).

 

F.eks. en kunde som trenger å få levert noen pakker. Han spør etter et firma som kan levere 10 pakker daglig - og ikke har mer enn 3 dagers leveringstid. Å da komme med et produkt som leverer 50 pakker daglig og leveringstid på 2 dager er da ikke noe som er verd å bruke penger på. Produktet er kanskje bedre, men kunden har rett og slett ikke bruk for det.

 

Edit2: Ble litt rot i innlegget. Poenger her er ikke om A er bedre kode enn B fordi A tok kortere tid å implementere. Det er et økonimisk spørsmål. Om det tar kortere tid å implementere A i forhold til B, men fordelene (ytelsesmessig) er av ubetydelig art. Så er det ofte bedre å implementere A enn B.

 

Eksempel er om du skal lage en algoritme som finner korteste vei fra A til B for bruk i en GPS. Du har en grei algoritme som kan finnes korteste vei mellom 2 vilkårlige punkter A og B på 100 millisekunder. Denne er veldig rask å implementere.

 

Alternativt vet du også om en annen implementasjon som kan gjøre dette på en tredjedel av tiden - men algoritmen er mer avansert og tar derfor mer tid å implementere. Spørsmålet er da, er det virkelig verd å implementere den?

 

Svaret blir da, spørs på bruksområde. Om dette var noe du implementerte for en GPS som "Johansen transport AS" skal bruke i sine trailere - så vil det ha lite å si om de må vente 30ms eller 100ms for å få veien sin kalkulert. Ventetiden er såpass ubetydelig, og veier derfor ikke opp for ekstra utviklingskostnader.

 

Derimot om dette systemet skulle kjøre sentralt på google sine systemer, og finne veien for alle som gjør søk i google-maps så ville dette kanskje være av relevans - da man i større grad må tenke på skalering.

Endret 14. januar 2013 av etse

[LonelyMan]

Men nå kommer vi tilbake til det at enten snakker du forretning eller så snakker du teknisk anlagt programmering.

 

Argumentet er: Enten kan du tjene mer penger eller så kan du bli bedre programmerer. Hele innlegget mitt handler om at det å forsøke å tjene mer penger ikke har noen ting med god programmering å gjøre til å begynne med. Du snakker forretning, det som lønner seg forretningsmessig er ikke noe grunnlag for å føre en diskusjon om hva god programmering er da forretning bygger på lette løsninger til å begynne med.

 

Det fins de av oss som ikke tenker forretning primært, men som er teknisk interesserte. Problemet oppstår når de som er forretningsmessig engasjert skal fortelle teknisk interesserte at en teknisk god løsning ikke er god, når den er det. Og så begrunne med at den ikke er god fordi den ikke gir nok inntekt. Det er hele poenget mitt.

Endret 14. januar 2013 av LonelyMan

[kim009]

Skal man jobbe som programmerer så har den økonomiske delen mye og si om hvor god man er som programmerer. Om A bruker 10x lenger tid en B på å løse en gitt oppgave men for den ekstra tiden så får A 3x bedre ytelse på koden en B så vill de fleste ansette B siden han vill generere mer penger for bedriften, med mindre det er kritisk at ytelsen på oppgaven er optimal samme hvor mye ekstra kostnadene vill bli. produksjons tid/kostnader er en veldig viktig ting på de aller fleste prosjekter og har derfor mye å si om hvor god en programmerer er.

 

Driver man med hobby koding for seg selv så spiller selvsakt ikke produksjons tid så mye lenger, med mindre man selv prioriterer det.

[LonelyMan]

Jeg ser på det sånn at den økonomiske biten er relevant for å konkurrere om ansettelsen, en programmerer kan vise til at han har X mer erfaring/ansiennitet eller Y mer kunnskap, men straks du begynner å si at fordi du tjener så godt, derfor har du best teknisk forståelse, det er her ting faller fra hverandre og ikke er fornuftig. Jobbintervjuer gjelder alt, hvilket inntrykk man gjør, erfaring, ansiennitet, kunnskap, utdannelse osv. Men den nærmeste konkurrenten vil alltid bære på den samme drivkraften at business er business, du lærer ikke mer enn du behøver å gi bedriften, og skjeldent er de spesielt tekniske på lavt nivå, de behøver ikke forstå datamaskinen's virkemåte på mikronivå eller hvordan man optimaliserer best mulig, men de må forstå et variert og bredt spekter av termer for en helhetlig vurdering til ansettelse, men ikke særlig spesialisert på noen måter.

Endret 14. januar 2013 av LonelyMan

[etse]

Er vel dette det fler av oss prøver å få frem, at man i dagens samfunn i realtiteten også må vurdere denne økonomiske delen. "Er det verd tiden det vil ta om jeg lærer meg dette - i det lange løp?".

 

Du sa det egentlig veldig kort og enkelt, kim009. Å skrive effektiv kode er bare en av tingene som beskriver en god utvikler. Men også ting som om utvikleren velger riktig verktøy til riktig jobb, skriver kode som er lett å vedlikeholde/utvide og hvor kort tid han bruker på å komme med et ferdig produkt. Dette kommer selvfølgelig av at de fleste av oss blir å jobbe i industrien hvor dette er en realtitet.

 

For hobbyprogrammerere og folk som jobber med research er ikke dette like mye en issue.

 

Jeg ser på det sånn at den økonomiske biten er relevant for å konkurrere om ansettelsen, en programmerer kan vise til at han har X mer erfaring/ansiennitet eller Y mer kunnskap, men straks du begynner å si at fordi du tjener så godt, derfor har du best teknisk forståelse, det er her ting faller fra hverandre og ikke er fornuftig.

Hvem her sier at høyere lønn == bedre teknisk forståelse?

 

Vi sier bare at god teknisk forståelse er ikke alt som beskriver en god programmerer. En god utvikler handler om mye mer enn kun å forstå det rent tekniske. Det å forstå kundens behov og levere deretter er også viktig for å være en god utvikler.

 

Det hjelper og lite om du har bedre teknisk forståelse, og en annen med mindre teknisk forståelse også kan levere det kunden trenger - men gjør det på en lettere måte og dermed bruker mindre tid og leverer til en lavere pris.

Endret 14. januar 2013 av etse

[LonelyMan]

etse, en utvikler er noe annet enn en programmerer eller en teknisk anlagt person. Utviklere må lære seg et bredt spekter av verktøy for å oppnå et mål å selge et produkt, teknisk anlagte er spesialister på et eller annet område.

Endret 14. januar 2013 av LonelyMan

[etse]

etse, en utvikler er noe annet enn en programmerer eller en teknisk anlagt person. Utviklere må lære seg et bredt spekter av verktøy, teknisk anlagte er spesialister på et eller annet område.

En programmerer og en utvikler kan da fint være akkurat det samme. En utvikler er gjerne en programmerer. Tekniske anlagte personer kan de også fint være. Disse er ikke forskjellige grupper.

 

Poenget ligger bare at om du skal være en god programmerer eller utvikler så er det viktig at man leverer etter spesifikasjoner - og ikke bryr seg med å overlevere.

 

Eksempel (siden du er så glad i eksempler): Om kunden ønsker et system som takler 1.000 besøkende i minuttet så er lite interesant om du lager et system som takler 1.500 besøkende per minutt eller 10.000 besøkende per minutt. Denne ytelsesforbedringen er av lite interesse for kunden - da han bare forespeilet 1.000 besøkende per minutt. Så om du vil bruke ekstra tid på å lage en system som er mer optimalisert for å takle langt mer enn spesifikasjonene til kunden må du nok ta kostnaden for det på egen kappe. Kunden er nok ikke interesert i å betale dette.

 

Vi snakker og her om å være en god utvikler / programmerer. Og det er her slike ting kommer inn i bilde. Det er selvfølgelig bra om en programmerer/utvikler kan mange av de meget gode implementasjonene som kan brukes i ulike scenarioer; men han burde og vite at den mest effektive løsningen ikke alltid er den riktige løsningen for det scenarioet han står i.

 

Om det å velge en mer effektiv implementasjon fører til lengre utviklingstid eller kode som er vanskeliggere å vedlikeholde for 3. part, så er det ofte ikke verd dette. Og en god programmerer vil møte slike problemstillinger ofte - og må ofte velge å gå for de lette løsningen som går fort å implementere.

Endret 14. januar 2013 av etse

[LonelyMan]

Ja men nå snakker ikke jeg til fordel for kjøp og salg, jeg snakket i favør av programmering og hva som er optimalt og hva som er best i programmering til enhver tid (det betyr ikke unødvendig optimalisering eller unødvendig sløsing med tid, men det betyr at man er interessert i programmering, interessert i det tekniske ved en datamaskin og setter pris på å forstå hvorfor X er bra og Y er verre)

 

Om en kunde krever 10,000 besøkende per minutt og jeg har hatt en god forståelse for et slikt program lenge før kunden ba om det og kanskje jeg hadde utviklet et slikt program, så tror jeg kunden likevel ville satt pris på om jeg kunne levere 50,000 per minutt for samme kostnad som konkurrenten gir for 15,000 per minutt. Det gir impression. Det å ha en sikkerhets-terskel å gå på gir trygghet, å vite at du alltid ligger langt innenfor trygghets sonen, det betyr noe, og ville ikke kostet ekstra, da jeg hadde forståelse for den typen programmer og laget et som var bedre enn konkurrenten sitt program. Det er ikke sikkert jeg brukte så veldig mye lengre tid på å utvikle det heller, det skal man ikke se bort ifra

 

Det BEHØVER ikke være forskjell på en teknisk anlagt, en utvikler og en programmerer, på lik linje som det ikke behøver være forskjell på en vaktmester og en piperenser, eller en snømåker og en brøytebil. Men semantikken spiller en rolle likevel. Alle vet at en lærer kan også være en sportsutøver, eller en politiker kan også være en diplomat. Men de forskjellige spesifikasjoner og yrker har likevel sine røtter i semantikken.

Endret 14. januar 2013 av LonelyMan

[etse]

Det er jo ingen som sier at mer kunskap er en dårlig ting. For alle er nok enige om at å bli få mer kkunskap alltid er viktig innenfor et slikt felt. Man må bare vite hva man skal gjøre i hvilken situasjon. F.eks. vil ikke iterative implementasjoner alltid være bedre enn rekursive. Og implementasjoner i C / assembly vil ofte vise seg å være langt i fra det beste i mange scenarioer.

 

Koden vil selvfølgelig være mer optimalisert, men den vil ofte ta lengre tid å skrive og være vanskeligere å vedlikeholde.

 

På samme måte kan man argumentere for mange andre alternativer og. Det er selvfølgelig greit å vite om alle de ulike måten man kan løse et problem på - men man må klare å innse at den mest effektive løsningen ikke alltid er den beste. Det er andre faktorer som også spiller inn.

 

Det BEHØVER ikke være forskjell på en teknisk anlagt, en utvikler og en programmerer, på lik linje som det ikke behøver være forskjell på en vaktmester og en piperenser, eller en snømåker og en brøytebil. Men semantikken spiller en rolle likevel. Alle vet at en lærer kan også være en sportsutøver, eller en politiker kan også være en diplomat. Men de forskjellige spesifikasjoner og yrker har likevel sine røtter i semantikken.

 

om et firma skriver at de ansetter en programmerer eller en utvikler (mer spesifikt kanskje programmvareutvikler) så er dette akkurat det samme om man ikke har mer kontekst. Man vil og ofte se at det i søknadsteksten står "Vi ønsker programmerer / utvikler". Med dette menes altså en person som kan skrive kode til å lage programmer. For å kunne få det noe mer detaljert må man ha flere opplysninger.

 

Edit: Man kan vel si at en utvikler er mer et fellesord som går over flere grener. Er man en utvikler så vet man ikke om du er en som utvikler biler, eller en som utvikler programmvare. Men er du er programmerere er du en person som utvikler programmvare.

 

(Altså alle utviklere er ikke programmerere, men alle programmerere er også utviklere)

Endret 14. januar 2013 av etse

[LonelyMan]

Du får ha din mening om det, jeg forsøker å holde et ryddig sted for disse definisjonene

 

Når det gjelder C / Assembly så fins det ingen standard måling for hvor raskt eller hvor effektivt assembly er for det fins en drøss med assemblere, og det fins ingen grenser for hvordan du bygger et assembler program. Du har f.eks masmbasic som er assembler med basic syntaks og du utvikler lynraske assembler programmer med hastighet på basic nivå.

Endret 14. januar 2013 av LonelyMan

[etse]

Du får ha din mening om det, jeg forsøker å holde et ryddig sted for disse definisjonene

 

Når det gjelder C / Assembly så fins det ingen standard måling for hvor raskt eller hvor effektivt assembly er for det fins en drøss med assemblere, og det fins ingen grenser for hvordan du bygger et assembler program. Du har f.eks masmbasic som er assembler med basic syntaks og du utvikler lynraske assembler programmer med hastighet på basic nivå.

nå kverulerer jeg litt, men hvor henter du definisjonene dine på hva en utvikler og hva en programmerer er fra? eller har du laget dine egne definisjoner som ikke hverken er hentet fra ordboken eller henger sammen med hva som blir brukt i dagligtalen?

 

En utvikler er en som utvikler et produkt (uansett gren)

Programmvareutvikler, en som lager programmvare

Programmerer, en som skriver kode, lager programmvare

 

Jeg har egentlig aldri opplevd at noen har brukt disse ordene på annen måte enn dette, før nå da. Jeg føler du her har laget deg enn litt egen definisjon av ordene.

 

Tror og du misset litt av poenget mitt med assembler / C. I mange tilfeller vil C / Assembly rett og slett ikke være riktig verktøy uansett om du kan skrive 10 ganger så effektiv kode, rett og slett fordi i mange tilfeller vil utviklingstiden være så mye lengre.

 

Eksempel er om kunden ønsker et program som f.eks. sjekker oppetiden på en server og gir et varsel om den ikke svarer innenfor et tidsintervall. Da vil det være betydelig raskere å utvikle dette programmet i et høynivåspråk fremfor i f.eks. C - og ytelsesforskjellen man får fra å bruke et lavnivå språk er egentlig ubetydelig siden man ikke vil merke forskjell i praksis.

(Dette eksempelet var litt satt på spissen, men viser hva jeg mener med å velge riktig verktøy til riktig jobb)