De 7 mest plagsomme problemer i programmeringen

Det er blevet sagt, at de ukendte territorier på de gamle kort ofte var markeret med den ildevarslende advarsel: "Her være drager." Måske apokryf, ideen var, at ingen, der vandrede ind i disse ukendte hjørner af verden, skulle gøre det uden at være klar til at kæmpe mod en skræmmende fjende. Alt kunne ske i disse mystiske regioner, og ofte var alting ikke godt.

Programmører kan være lidt mere civiliserede end middelalderlige riddere, men det betyder ikke, at den moderne tekniske verden ikke har sin andel af tekniske drager, der venter på os på uforudsete steder: Vanskelige problemer, der venter, indtil deadline er minutter væk; komplikationer, der har læst manualen og ved, hvad der ikke er godt specificeret; onde drager, der ved, hvordan man sniger sig ind i tomme bugs og utilsigtede fejl, ofte lige efter at koden er begået.

Der vil være nogle, der hviler stille om natten, opvarmet af deres naive selvsikkerhed om, at computere er fuldstændigt forudsigelige, og som alvorligt slår de rigtige svar ud. Åh, hvor lidt de ved. På trods af alt hårdt arbejde fra chipdesignere, sprogudviklere og millioner af programmører overalt er der stadig tornede krat af programmeringsproblemer, der kan bringe selv de mægtigste programmører på knæ.

Her er syv af de knapeste hjørner af programmeringsverdenen, hvor vi vil sætte store markører, der læser: "Her være drager."

Multithreading

Det lød som en god idé: Opdel dit program i uafhængige sektioner, og lad operativsystemet køre dem som separate små programmer. Hvis processorer har fire, seks, otte eller endnu flere kerner, hvorfor ikke skrive din kode, så den kan have fire, seks, otte eller flere tråde, der bruger alle kernerne uafhængigt?

Ideen fungerer - når delene faktisk er helt adskilte og ikke har noget at gøre med hinanden. Men når de har brug for at få adgang til de samme variabler eller skrive bits til de samme filer, er alle væddemål slået fra. En af trådene kommer først til dataene, og du kan ikke forudsige, hvilken tråd det bliver.

Således opretter vi skærme, semaforer og andre værktøjer til at organisere det multitrådede rod. Når de arbejder, arbejder de. De tilføjer blot endnu et lag af kompleksitet og gør handlingen med lagring af data i en variabel til et element, der kræver lidt mere eftertanke.

Når de ikke arbejder, er det rent kaos. Dataene giver ikke mening. Kolonnerne tilføjes ikke. Penge forsvinder fra konti med et poof. Det er alle bits i hukommelsen. Og held og lykke med at prøve at fastgøre noget af det. Det meste af tiden ender udviklere med at låse store klumper af datastrukturen ned, så kun en tråd kan røre ved den. Det kan hæmme kaoset, men kun ved at dræbe det meste af forsiden af at have flere tråde, der arbejder på de samme data. Du kan lige så godt omskrive det som et "single-threaded" program.

Lukninger

Et eller andet sted langs linjen besluttede nogen, at det ville være nyttigt at videregive funktioner som om de var data. Dette fungerede godt i enkle tilfælde, men programmører begyndte at indse, at der opstod problemer, når funktioner nåede uden for sig selv og fik adgang til andre data, ofte kaldet "gratis variabler." Hvilken version var den rigtige? Var det dataene, da funktionsopkaldet blev startet? Eller var det da funktionen faktisk kørte? Dette er især vigtigt for JavaScript, hvor der kan være lange huller imellem.

Løsningen, "lukningen", er en af de største kilder til hovedpine for JavaScript (og nu Java og Swift) programmerere. Nybegyndere og endda mange veteraner kan ikke finde ud af, hvad der lukkes, og hvor grænserne for den såkaldte lukning kan være.

Navnet hjælper ikke - det er ikke som om adgang lukkes permanent som en bar, der annoncerer sidste opkald. Hvis det er tilfældet, er adgangen åben, men kun gennem et ormehul i datatidskontinuumet, en mærkelig tidsforskydningsmekanisme, der i sidste ende vil gyde et sci-fi-tv-show. Men at kalde det en "Complex Stack Access Mechanism" eller "Data Control Juggling System" virker for lang, så vi sidder fast med "lukninger". Lad mig ikke komme i gang med, om nogen skal betale for de ikke-gratis variabler.

For store data

Når RAM begynder at fylde op, begynder alt at gå galt. Det betyder ikke noget, om du udfører nyudviklet statistisk analyse af forbrugerdata eller arbejder på et kedeligt, gammelt regneark. Når maskinen løber tør for RAM, bliver den til såkaldt virtuel hukommelse, der spilder ud på den superslow harddisk. Det er bedre end at gå helt ned eller afslutte jobbet, men dreng gør alt sammen.

Problemet er, at harddiske er mindst 20 eller 30 gange langsommere end RAM, og diskdrev på massemarkedet ofte er langsommere. Hvis en anden proces også forsøger at skrive eller læse fra disken, bliver alt dramatisk værre, fordi drevene kun kan gøre en ting ad gangen.

Aktivering af den virtuelle hukommelse forværrer andre skjulte problemer med din software. Hvis der er trådfejl, begynder de at bryde meget hurtigere, fordi de tråde, der sidder fast i harddiskens virtuelle hukommelse, kører så meget langsommere end de andre tråde. Det varer dog kun en kort periode, fordi de engang wallflower-tråde byttes ind i hukommelsen, og de andre tråde hænger op. Hvis koden er perfekt, er resultatet blot meget langsommere. Hvis det ikke er tilfældet, sender fejlene det hurtigt i katastrofe. Det er et lille eksempel.

Administration af dette er en reel udfordring for programmører, der arbejder med store bunker af data. Enhver, der bliver lidt sjusket med at opbygge spildte datastrukturer, ender med kode, der sænkes til en gennemgang i produktionen. Det fungerer muligvis fint med et par testsager, men rigtige belastninger sender det til at gå i svigt.

NP-komplet

Enhver med en universitetsuddannelse inden for datalogi kender til de mystiske problemer indpakket i et akronym, der sjældent er beskrevet: ikke-deterministisk polynom, komplet, også kaldet NP-komplet. Detaljerne tager ofte et helt semester at lære, og selv da kommer mange CS-studerende med en tåget opfattelse af, at ingen kan løse disse problemer, fordi de er for hårde.

NP-komplette problemer er ofte ret vanskelige - hvis du blot angriber dem med brutal kraft. For eksempel kan det "rejse sælgerproblem" tage lang tid, da salgsruten inkluderer flere og flere byer. Løsning af et "rygsækproblem" ved at finde et undersæt af tal, der kommer tættest på en værdi N, løses ved at prøve alle mulige undergrupper, hvilket er et meget stort tal. Alle løber med frygt for disse problemer, fordi de er det perfekte eksempel på en af de største bogeymen i Silicon Valley: algoritmer, der ikke skaleres.

Den vanskelige del er, at nogle NP-komplette problemer er lette at løse med en tilnærmelse. Algoritmerne lover ikke den nøjagtige løsning, men de kommer temmelig tæt på. De finder muligvis ikke den perfekte rute til den rejsende sælger, men de kan komme inden for få procentpoint af det rigtige svar.

Eksistensen af disse ret gode løsninger gør kun dragerne mere mystiske. Ingen kan være sikre på, om problemerne virkelig er hårde eller lette nok, hvis du er villig til at blive tilfreds med et svar, der bare er godt nok.

Sikkerhed

”Der er kendt kendskab; der er ting, vi ved, vi ved, ”sagde Donald Rumsfeld, forsvarsministeren under den anden Bush-administration, engang på en pressekonference. ”Vi ved også, at der er kendte ukendte; det vil sige, at vi ved, at der er nogle ting, vi ikke ved. Men der er også ukendte ukendte - dem, vi ikke ved, vi ikke kender. "

Rumsfeld talte om krigen i Irak, men det samme gælder for computersikkerhed. De største problemer er huller, som vi ikke engang ved, er mulige. Alle forstår, at du skal gøre dit kodeord svært at gætte - det er kendt. Men hvem er nogensinde blevet fortalt, at din netværkshardware har sit eget softwarelag begravet inde? Muligheden for, at nogen kan springe over hacking af dit operativsystem og i stedet målrette mod dette hemmelige lag, er ukendt ukendt.

Muligheden for den slags hack er måske ikke ukendt for dig nu, men hvad hvis der er andre? Vi har ingen anelse om, hvorvidt vi kan hærde de huller, vi ikke engang ved, eksisterer. Du kan lægge adgangskoderne ned, men der er revner, du ikke engang kan forestille dig. Det er sjovt at arbejde med computersikkerhed. Og når det kommer til programmering, bliver sikkerhedssindet tænkning stadig vigtigere. Du kan ikke overlade det til sikkerhedsmændene at rydde op i dit rod.

Kryptering

Kryptering lyder kraftigt og uigennemtrængelig, når retshåndhævende embedsmænd kommer foran kongressen og beder om officielle smuthuller for at stoppe den. Problemet er, at mest kryptering er bygget på en tåget sky af usikkerhed. Hvilke matematiske beviser vi hviler på usikre antagelser, som om det er svært at faktorere virkelig store tal eller beregne en diskret log.

Er disse problemer virkelig hårde? Ingen har offentligt beskrevet nogen algoritmer til at bryde dem, men det betyder ikke, at løsningerne ikke findes. Hvis du fandt en måde at aflytte hver samtale og bryde ind i en bank, ville du straks fortælle verdenen og hjælpe dem med at sætte hullerne i? Eller ville du forblive tavs?

Den virkelige udfordring er at bruge kryptering i vores egen kode. Selvom vi stoler på, at de grundlæggende algoritmer er sikre, er der meget arbejde, der skal udføres med jonglering af adgangskoder, nøgler og forbindelser. Hvis du laver en fejl og efterlader en adgangskode ubeskyttet, falder alt åbent.

Identitetsstyring

Alle elsker den New Yorker-tegneserie med punchline: "På internettet ved ingen, at du er en hund." Det har endda sin egen Wikipedia-side med fire detaljerede sektioner. (På Internettet kender ingen den gamle sav om at analysere humor og dissekere frøer.)

Den gode nyhed er, at anonymitet kan være befriende og nyttig. Den dårlige nyhed er, at vi ikke har nogen anelse om, hvordan vi gør andet end anonym kommunikation. Nogle programmører taler om "tofaktorautentificering", men de smarte springer til "N-faktorgodkendelse."

Efter adgangskoden og måske en tekstbesked til en mobiltelefon har vi ikke meget, der er meget stabilt. Fingeraftrykslæsere ser imponerende ud, men mange mennesker synes at være villige til at afsløre, hvordan de kan hackes (se her, her og her for startere).

Ikke meget af dette betyder noget for en verden af ledig snak på Snapchat eller Reddit, men strømmen af hackede Facebook-sider er lidt foruroligende. Der er ingen nem måde at håndtere alvorlige sager som ejendom, penge, sundhedspleje eller stort set alt andet i livet undtagen meningsløs small talk. Bitcoin fanbois elsker at skvælge om, hvor bunnsolid blockchain kan være, men på en eller anden måde bliver mønterne revet af (se her og her). Vi har ingen reel metode til at håndtere identitet.

Måling af hårdhed

Selvfølgelig, når det kommer til programmering, er der endda en måde, hvorpå vi kan måle vanskeligheden ved et problem? Ingen ved det rigtig. Vi ved, at nogle problemer er lette at løse, men det er helt anderledes at certificere en som hård. NP-fuldstændighed er kun en del af et detaljeret forsøg på at kodificere kompleksiteten af algoritmer og dataanalyse. Teorien er nyttig, men den kan ikke give nogen garantier. Det er fristende at sige, at det er svært selv at vide, om et problem er svært, men godt, du får vittigheden.