Det er blitt sagt at de ukjente områdene til de gamle kartene ofte ble markert med den illevarslende advarselen: "Her være drager." Kanskje apokryf, ideen var at ingen som vandrer inn i disse ukjente hjørner av verden skulle gjøre det uten å være klar til å kjempe mot en skremmende fiende. Alt kan skje i disse mystiske områdene, og ofte at alt ikke var bra.
Programmerere er kanskje litt mer siviliserte enn middelalderske riddere, men det betyr ikke at den moderne tekniske verden ikke har sin andel av tekniske drager som venter på oss på uforutsette steder: Vanskelige problemer som venter til fristen er minutter unna; komplikasjoner som har lest håndboken og vet hva som ikke er spesifisert; onde drager som vet hvordan de skal snike seg inn i tomme bugs og utidig feil, ofte rett etter at koden er begått.
Det vil være noen som hviler stille om natten, oppvarmet av sin naive selvsikkerhet om at datamaskiner er helt forutsigbare, og seriøst oppretter de riktige svarene. Å, hvor lite de vet. For alt hardt arbeid fra chipdesignere, språkutviklere og millioner av programmerere overalt, er det fremdeles tornete kratt med programmeringsproblemer som kan bringe selv de mektigste programmørene på kne.
Her er syv av de mest knuste hjørnene i programmeringsverdenen der vi vil sette store markører som leser: "Her være drager."
Multitrading
Det hørtes ut som en god idé: Bryt opp programmet ditt i uavhengige seksjoner og la operativsystemet kjøre dem som separate små programmer. Hvis prosessorene har fire, seks, åtte eller enda flere kjerner, hvorfor ikke skrive koden din slik at den kan ha fire, seks, åtte eller flere tråder ved å bruke alle kjernene uavhengig?
Ideen fungerer - når delene faktisk er helt separate og ikke har noe å gjøre med hverandre. Men når de trenger å få tilgang til de samme variablene eller skrive biter til de samme filene, er alle spill av. En av trådene kommer til dataene først, og du kan ikke forutsi hvilken tråd det vil være.
Dermed lager vi skjermer, semaforer og andre verktøy for å organisere det flertrådede rotet. Når de jobber, jobber de. De legger bare til et nytt kompleksitetslag og gjør handlingen med å lagre data i en variabel til et element som krever litt mer tanke.
Når de ikke jobber, er det rent kaos. Dataene gir ikke mening. Kolonnene legges ikke sammen. Penger forsvinner fra kontoer med et poof. Det er alle biter i minnet. Og lykke til med å prøve å finne ut noe av det. Mesteparten av tiden ender utviklerne med å låse store biter av datastrukturen slik at bare en tråd kan berøre den. Det kan føre til kaoset, men bare ved å drepe det meste av oppsiden av å ha flere tråder som jobber med de samme dataene. Du kan like godt omskrive det som et “single-threaded” program.
Stengninger
Et eller annet sted langs linjen bestemte noen seg for at det ville være nyttig å formidle funksjoner som om de var data. Dette fungerte bra i enkle tilfeller, men programmerere begynte å innse at problemer oppstod når funksjoner nådde utenfor seg selv og fikk tilgang til andre data, ofte kalt "gratis variabler." Hvilken versjon var den rette? Var det dataene da funksjonssamtalen ble startet? Eller var det da funksjonen faktisk kjører? Dette er spesielt viktig for JavaScript der det kan være lange hull i mellom.
Løsningen, "lukkingen", er en av de største kildene til hodepine for JavaScript (og nå Java og Swift) programmerere. Nybegynnere og til og med mange veteraner kan ikke finne ut hva som blir stengt, og hvor grensene for den såkalte nedleggelsen kan være.
Navnet hjelper ikke - det er ikke slik at tilgangen lukkes permanent som en bar som kunngjør siste samtale. Om noe er tilgangen åpen, men bare gjennom et ormehull i datatids kontinuum, en merkelig tidsforskyvningsmekanisme som til slutt vil gyte et sci-fi TV-show. Men å kalle det en "Complex Stack Access Mechanism" eller "Data Control Juggling System" virker for lang, så vi sitter fast med "nedleggelser". Ikke få meg i gang med om noen trenger å betale for de ikke-gratis variablene.
For store data
Når RAM begynner å fylles, begynner alt å gå galt. Det spiller ingen rolle om du utfører nybegynnerlig statistisk analyse av forbrukerdata eller jobber med et kjedelig, gammelt regneark. Når maskinen går tom for RAM, blir den til såkalt virtuelt minne som søler ut på den superslow harddisken. Det er bedre enn å krasje helt eller avslutte jobben, men gutt gjør alt.
Problemet er at harddisker er minst 20 eller 30 ganger tregere enn RAM, og diskstasjonene på massemarkedet ofte er tregere. Hvis en annen prosess også prøver å skrive eller lese fra disken, blir alt dramatisk verre fordi stasjonene bare kan gjøre en ting om gangen.
Aktivering av det virtuelle minnet forverrer andre skjulte problemer med programvaren. Hvis det er tråkkfeil, begynner de å bryte mye raskere fordi trådene som sitter fast i harddiskens virtuelle minne, går så mye tregere enn de andre trådene. Det varer bare en kort periode, fordi de en gang veggblomstertrådene blir byttet ut i minnet og de andre trådene legger på. Hvis koden er perfekt, blir resultatet bare mye tregere. Hvis ikke, vil feilene raskt føre til at det krasjer i katastrofe. Det er et lite eksempel.
Å administrere dette er en reell utfordring for programmerere som jobber med store bunker med data. Alle som blir litt slurvete med å bygge bortkastede datastrukturer, ender opp med kode som bremser til en gjennomgang i produksjonen. Det kan fungere bra med noen få testtilfeller, men virkelige belastninger sender det til å mislykkes.
NP-komplett
Alle som har en universitetsutdannelse innen informatikk, kjenner til de mystiske problemene som er pakket inn i et akronym som sjelden er skrevet ut: ikke-deterministisk polynom, komplett, også kjent som NP-komplett. Det tar ofte et helt semester å lære detaljene, og selv da kommer mange CS-studenter med en tåket forestilling om at ingen kan løse disse problemene fordi de er for harde.
NP-komplette problemer er ofte ganske vanskelige - hvis du bare angriper dem med brutal kraft. «Reisende selgerproblem», kan for eksempel ta eksponentielt lang tid ettersom salgsruten inkluderer flere og flere byer. Å løse et "ryggsekkproblem" ved å finne en delmengde av tall som kommer nærmest noen verdi N løses ved å prøve alle mulige delmengder, som er et veldig stort tall. Alle løper med frykt for disse problemene fordi de er det perfekte eksempelet på en av de største skurkene i Silicon Valley: algoritmer som ikke skaleres.
Den vanskelige delen er at noen NP-komplette problemer er enkle å løse med en tilnærming. Algoritmene lover ikke den eksakte løsningen, men de kommer ganske nært. De finner kanskje ikke den perfekte ruten for den reisende selgeren, men de kan komme innenfor noen få prosentpoeng av riktig svar.
Eksistensen av disse ganske gode løsningene gjør bare dragene mer mystiske. Ingen kan være sikre på om problemene er virkelig vanskelige eller enkle nok hvis du er villig til å bli fornøyd med et svar som bare er godt nok.
Sikkerhet
“Det er kjent kunnskap; det er ting vi vet vi vet, ”sa Donald Rumsfeld, forsvarsministeren under den andre Bush-administrasjonen, en gang på en pressekonferanse. “Vi vet også at det er kjente ukjente; det vil si at vi vet at det er noen ting vi ikke vet. Men det er også ukjente ukjente - de vi ikke vet vi ikke kjenner. "
Rumsfeld snakket om krigen i Irak, men det samme gjelder datasikkerhet. De største problemene er hull som vi ikke en gang vet er mulige. Alle forstår at du bør gjøre passordet ditt vanskelig å gjette - det er kjent. Men hvem har noen gang blitt fortalt at nettverksmaskinvaren din har sitt eget programvarelag begravet inne? Muligheten for at noen kan hoppe over hacking av operativsystemet ditt og i stedet målrette dette hemmelige laget er ukjent ukjent.
Muligheten for den slags hack er kanskje ikke ukjent for deg nå, men hva om det er andre? Vi har ingen anelse om vi kan herde hullene vi ikke engang vet eksisterer. Du kan legge ned passordene, men det er sprekker du ikke en gang kan forestille deg. Det er moroa med å jobbe med datasikkerhet. Og når det kommer til programmering, blir sikkerhetsinnstilte tanker stadig viktigere. Du kan ikke overlate til sikkerhetsproffene å rydde opp i rotet.
Kryptering
Kryptering høres kraftig ut og ugjennomtrengelig når politimyndigheter kommer foran kongressen og ber om offisielle smutthull for å stoppe den. Problemet er at mest kryptering er bygget på en tåket sky av usikkerhet. Hvilke matematiske bevis vi har hviler på usikre forutsetninger, som om det er vanskelig å faktorere virkelig store tall eller beregne en diskret logg.
Er disse problemene virkelig vanskelige? Ingen har offentlig beskrevet noen algoritmer for å bryte dem, men det betyr ikke at løsningene ikke eksisterer. Hvis du fant en måte å lytte til hver samtale og bryte inn i en hvilken som helst bank, vil du umiddelbart fortelle verden og hjelpe dem å plugge hullene? Eller ville du være stille?
Den virkelige utfordringen er å bruke kryptering i vår egen kode. Selv om vi stoler på at de grunnleggende algoritmene er sikre, er det mye arbeid å gjøre med å jonglere passord, nøkler og tilkoblinger. Hvis du gjør en feil og lar et passord være ubeskyttet, faller alt åpent.
Identitetsstyring
Alle elsker den New Yorker-tegneserien med punchline: "På internett vet ingen at du er en hund." Den har til og med sin egen Wikipedia-side med fire forseggjorte seksjoner. (På internett vet ingen den gamle sagen om å analysere humor og dissekere frosker.)
Den gode nyheten er at anonymitet kan være frigjørende og nyttig. Den dårlige nyheten er at vi ikke har noen anelse om hvordan vi kan gjøre annet enn anonym kommunikasjon. Noen programmerere snakker om "tofaktorautentisering", men de smarte hopper til "N-faktorautentisering."
Etter passordet og kanskje en tekstmelding til en mobiltelefon har vi ikke mye som er veldig stabilt. Fingeravtrykklesere ser imponerende ut, men mange mennesker ser ut til å være villige til å røpe hvordan de kan bli hacket (se her, her og her for det første).
Ikke mye av dette betyr noe for en verden av ledig chatter på Snapchat eller Reddit, men strømmen av hackede Facebook-sider er litt foruroligende. Det er ingen enkel måte å håndtere alvorlige saker som eiendom, penger, helsevesen eller stort sett alt annet i livet unntatt meningsløst småprat. Bitcoin fanbois elsker å snakke om hvor solid solid blockchain kan være, men på en eller annen måte blir myntene dratt av (se her og her). Vi har ingen reell metode for å håndtere identitet.
Måle hardhet
Selvfølgelig, når det kommer til programmering, er det til og med en måte vi kan måle vanskeligheten med et problem på? Ingen vet det egentlig. Vi vet at noen problemer er enkle å løse, men det er helt annerledes å sertifisere en som vanskelig. NP-fullstendighet er bare en del av et forseggjort forsøk på å kodifisere kompleksiteten i algoritmer og dataanalyse. Teorien er nyttig, men den kan ikke gi noen garantier. Det er fristende å si at det er vanskelig å til og med vite om et problem er vanskelig, men vel, du får vitsen.
Relaterte artikler
- Nedlasting: Utviklerveiledning for karriereutvikler
- Kraften til lat programmering
- 7 dårlige programmeringsideer som fungerer
- 9 dårlige programmeringsvaner vi i hemmelighet elsker
- 21 varme programmeringstrender - og 21 blir kalde
- Nedlasting: Den profesjonelle programmererens guide for virksomhetsoverlevelse
- Nedlasting: 29 tips for å lykkes som uavhengig utvikler
- 7 programmeringsspråk vi elsker å hate
- 5 flere tidløse leksjoner med programmering av 'gråskjegg'
- 22 fornærmelser ingen utviklere ønsker å høre
- 9 spådommer for fremtiden for programmering
- De 13 utviklerferdighetene du trenger å mestre nå
- Programmer verden: 12 teknologier du trenger å kjenne til nå
- Angrep av programmeringsspråkene på en bokstav
