Seitsemän kauhistuttavaa ongelmaa ohjelmoinnissa

Sanotaan, että vanhojen karttojen kartoittamattomat alueet on usein merkitty pahaenteisellä varoituksella: "Tule lohikäärmeitä." Ehkä apokryfinen, ajatus oli, että kenenkään näiden tuntemattomiin kolkiin vaeltavien ei pitäisi tehdä niin olematta valmiita taistelemaan kauhistuttavaa vihollista vastaan. Näillä salaperäisillä alueilla mitä tahansa voi tapahtua, ja usein mikään ei ollut hyvää.

Ohjelmoijat voivat olla hieman sivistyneempiä kuin keskiaikaiset ritarit, mutta se ei tarkoita, että nykyaikaisessa teknisessä maailmassa ei ole osuuttaan teknisistä lohikäärmeistä odottamassa meitä odottamattomissa paikoissa: Vaikeat ongelmat, jotka odottavat, että määräaika on minuuttien päässä; komplikaatiot, jotka ovat lukeneet käyttöohjetta ja tietävät, mitä ei ole määritelty hyvin; pahat lohikäärmeet, jotka osaavat hiipiä tuuman virheistä ja ennenaikaisista häiriöistä, usein heti koodin tekemisen jälkeen.

On joitain, jotka lepäävät hiljaa yöllä lämmitettynä naiivilla itsevarmuudellaan siitä, että tietokoneet ovat täysin ennustettavissa ja vilpittömästi oikeat vastaukset. Kuinka vähän he tietävät. Kaikista sirusuunnittelijoiden, kielikehittäjien ja miljoonien ohjelmoijien kaikesta ahkerasta työstä huolimatta on edelleen vaikeita ohjelmointiongelmia, jotka voivat jopa mahtavimmat ohjelmoijat polvistua.

Tässä on seitsemän ohjelmointimaailman harmainta kulmaa, joihin laittaisimme suuret merkinnät lukemaan "Täällä olla lohikäärmeitä".

Monisäikeinen

Se kuulosti hyvältä ajatukselta: Jaa ohjelma itsenäisiksi osioiksi ja anna käyttöjärjestelmän suorittaa ne kuin erilliset pienet ohjelmat. Jos prosessoreilla on neljä, kuusi, kahdeksan tai jopa enemmän ytimiä, miksi ei kirjoittaisi koodiasi niin, että siinä voi olla neljä, kuusi, kahdeksan tai enemmän säikeitä, jotka käyttävät kaikkia ytimiä itsenäisesti?

Idea toimii - kun osat ovat itse asiassa täysin erillisiä eikä niillä ole mitään tekemistä toistensa kanssa. Mutta kun heidän on käytettävä samoja muuttujia tai kirjoitettava bittiä samoihin tiedostoihin, kaikki vedot ovat pois käytöstä. Yksi säikeistä menee ensin tietoihin, etkä voi ennustaa, mistä ketjusta se tulee.

Siksi luomme näyttöjä, semaforeja ja muita työkaluja monisäikeisen sotkun järjestämiseen. Kun he työskentelevät, he työskentelevät. Ne vain lisäävät toisen monimutkaisuuden ja muuttavat muuttujan tietojen tallentamisen kohteeksi, joka vaatii hieman enemmän miettimistä.

Kun ne eivät toimi, se on puhdasta kaaosta. Tiedot eivät ole järkeviä. Sarakkeita ei lasketa yhteen. Raha katoaa tileiltä, joissa on pölyä. Kaikki on muistissa. Ja onnea yrittäessäni selvittää mikä tahansa siitä. Suurimman osan ajasta kehittäjät lukitsevat tietorakenteen suuret palat siten, että vain yksi lanka voi koskettaa sitä. Se voi estää kaaoksen, mutta vain tappamalla suurimman osan siitä, että useat ketjut työskentelevät samojen tietojen kanssa. Voit myös kirjoittaa sen uudelleen "yksisäikeisenä" ohjelmana.

Sulkimet

Jossain linjalla, joku päätti, että olisi hyödyllistä siirtää toiminnot ympäriinsä kuin ne olisivat tietoja. Tämä toimi hyvin yksinkertaisissa tapauksissa, mutta ohjelmoijat alkoivat ymmärtää, että ongelmia ilmeni, kun toiminnot ulottuvat itsensä ulkopuolelle ja käyttävät muita tietoja, joita usein kutsutaan "vapaiksi muuttujiksi". Mikä versio oli oikea? Oliko se tietoja, kun toimintokutsu aloitettiin? Vai oliko se silloin, kun toiminto todella suoritettiin? Tämä on erityisen tärkeää JavaScriptille, jossa niiden välissä voi olla pitkiä aukkoja.

Ratkaisu, "sulkeminen", on yksi suurimmista päänsärkyjen lähteistä JavaScript-ohjelmoijille (ja nyt Java ja Swift). Aloittelijat ja jopa monet veteraanit eivät pysty selvittämään, mitä suljetaan ja missä ns. Sulkemisen rajat voivat olla.

Nimi ei auta - se ei ole kuin pääsy suljetaan pysyvästi, kuten palkki, joka ilmoittaa viimeisestä puhelusta. Jos jotain, pääsy on avoin, mutta vain matoaukon kautta data-ajan jatkumossa, outo ajansiirtomekanismi, joka on pakko lopulta synnyttää scifi-TV-ohjelman. Mutta kutsuminen sitä "monimutkaiseksi pinon käyttömekanismiksi" tai "tietojen hallinnan jongleerausjärjestelmäksi" tuntuu liian pitkältä, joten olemme kiinni "sulkemisista". Älä anna minun aloittaa, tarvitseeko kenenkään maksaa maksuttomista muuttujista.

Liian iso data

Kun RAM alkaa täyttyä, kaikki alkaa mennä pieleen. Sillä ei ole merkitystä, suoritatko uuden tiedon tilastollista analyysiä kuluttajatiedoista vai työskenteletkö tylsällä, vanhalla laskentataulukolla. Kun koneessa loppuu RAM-muisti, se siirtyy niin kutsutuksi virtuaalimuistiksi, joka valuu supershow-kiintolevylle. Se on parempi kuin kaatua kokonaan tai lopettaa työ, mutta poika tekee kaiken hidastuvan.

Ongelmana on, että kiintolevyt ovat vähintään 20 tai 30 kertaa hitaampia kuin RAM ja massamarkkinat ovat usein hitaampia. Jos jokin muu prosessi yrittää myös kirjoittaa tai lukea levyltä, kaikki pahenee dramaattisesti, koska asemat voivat tehdä vain yhden asian kerrallaan.

Virtuaalimuistin aktivointi pahentaa muita, piilotettuja ongelmia ohjelmistossasi. Jos langoitusongelmia on, ne alkavat rikkoutua paljon nopeammin, koska kiintolevyn virtuaalimuistiin jumittuneet säikeet juoksevat niin paljon hitaammin kuin muut säikeet. Se kestää kuitenkin vain lyhyen ajan, koska kerran seinäkukka-langat vaihdetaan muistiin ja muut langat ripustavat. Jos koodi on täydellinen, tulos on vain paljon hitaampi. Jos se ei ole, virheet lähettävät sen nopeasti katastrofiin. Se on yksi pieni esimerkki.

Tämän hallinta on todellinen haaste ohjelmoijille, jotka työskentelevät suurilla tietopinoilla. Jokainen, joka saa vähän huolimattomasti tuhlaavien tietorakenteiden rakentamisesta, pääsee koodiin, joka hidastuu indeksointiin tuotannossa. Se voi toimia hyvin muutamalla testitapauksella, mutta todelliset kuormat lähettävät sen spiraaliksi vikaantumiseksi.

NP-täydellinen

Jokainen, jolla on korkeakoulututkinto tietojenkäsittelytieteessä, tietää salaperäisistä ongelmista, jotka on kääritty lyhenteessä, joka on harvoin täsmennetty: epädeterministinen polynomi täydellinen, alias NP-täydellinen. Yksityiskohtien oppiminen vie usein koko lukukauden, ja silloinkin monilla CS-opiskelijoilla on sumuinen käsitys siitä, että kukaan ei voi ratkaista näitä ongelmia, koska ne ovat liian kovia.

NP-täydelliset ongelmat ovat usein melko vaikeita - jos hyökkäät niihin yksinkertaisesti raakalla voimalla. Esimerkiksi "matkustavan myyjän ongelma" voi kestää eksponentiaalisesti kauan, koska myyntireitti sisältää yhä enemmän kaupunkeja. ”Selkäreppuongelman” ratkaiseminen etsimällä osajoukko numeroita, jotka ovat lähinnä arvoa N, ratkaistaan kokeilemalla kaikkia mahdollisia osajoukkoja, mikä on erittäin suuri luku. Kaikki juoksevat peloissaan näistä ongelmista, koska ne ovat täydellinen esimerkki yhdestä Piilaakson suurimmista bogeymeneistä: algoritmeja, joita ei laajenneta.

Haastava osa on, että jotkut NP-täydelliset ongelmat on helppo ratkaista likiarvolla. Algoritmit eivät lupa tarkkaa ratkaisua, mutta ne ovat melko lähellä. He eivät välttämättä löydä täydellistä reittiä matkustavalle myyjälle, mutta voivat päästä muutaman prosenttiyksikön sisällä oikeasta vastauksesta.

Näiden melko hyvien ratkaisujen olemassaolo tekee lohikäärmeistä vain salaperäisempiä. Kukaan ei voi olla varma, ovatko ongelmat todella tarpeeksi vaikeita tai helppoja, jos olet valmis tyydyttämään vastauksen, joka on tarpeeksi hyvä.

Turvallisuus

”Tunnettuja tunnettuja henkilöitä on; on asioita, jotka tiedämme tietävän ", toisen puolustusministeri Donald Rumsfeld sanoi kerran Bushin toisena lehdistötilaisuudessa. ”Tiedämme myös, että tunnettuja tuntemattomia on; eli tiedämme, että on joitain asioita, joita emme tiedä. Mutta on myös tuntemattomia tuntemattomia - niitä, joita emme tiedä, emme tiedä. "

Rumsfeld puhui Irakin sodasta, mutta sama pätee myös tietoturvaan. Suurimmat ongelmat ovat reikiä, joita emme edes tiedä olevan mahdollisia. Kaikki ymmärtävät, että salasanasi on vaikea arvailla - se tunnetaan tunnetusti. Mutta kenelle on koskaan kerrottu, että verkkolaitteistosi on haudattu oma ohjelmistokerros? Mahdollisuus, että joku voisi ohittaa käyttöjärjestelmän hakkeroinnin ja kohdistaa sen sijaan tähän salainen kerrokseen, on tuntematon tuntematon.

Tällaisen hakkeroinnin mahdollisuus ei ehkä ole sinulle tuntematon nyt, mutta entä jos muita on? Meillä ei ole aavistustakaan, jos pystymme kovettamaan reiät, joita emme edes tiedä olevan olemassa. Voit piilottaa salasanat, mutta on halkeamia, joita et voi edes kuvitella. Se on hauskaa työskennellä tietoturvan kanssa. Ja kun on kyse ohjelmoinnista, turvallisuusajatteleva ajattelu on yhä tärkeämpää. Et voi jättää sotaa siivoamaan turvallisuusammattilaisille.

Salaus

Salaus kuulostaa voimakkaalta ja läpäisemättömältä, kun lainvalvontaviranomaiset pääsevät kongressin eteen ja pyytävät virallisia porsaanreikiä sen lopettamiseksi. Ongelmana on, että suurin osa salauksesta on rakennettu sumuiselle epävarmuuspilvelle. Mitkä matemaattiset todisteet meillä ovat epävarmoissa oletuksissa, kuten on vaikea laskea todella suuria lukuja tai laskea erillinen loki.

Ovatko nuo ongelmat todella vaikeita? Kukaan ei ole julkisesti kuvannut mitään algoritmeja niiden rikkomiseksi, mutta se ei tarkoita, että ratkaisuja ei ole olemassa. Jos löysit tapan salakuunnella jokaista keskustelua ja murtautua mihin tahansa pankkiin, kertoisitko viipymättä maailmalle ja autat heitä täyttämään aukot? Vai pysyisitkö hiljaa?

Todellinen haaste on käyttää salausta omassa koodissamme. Vaikka luotamme perusalgoritmien turvallisuuteen, salasanojen, avainten ja yhteyksien salakuljetuksella on paljon tehtävää. Jos teet yhden virheen ja jätät salasanan suojaamattomaksi, kaikki jää auki.

Identiteetin hallinta

Kaikki rakastavat New Yorkerin sarjakuvaa, jossa on lyöntiä: "Internetissä kukaan ei tiedä, että olet koira" Sillä on jopa oma Wikipedia-sivu, jossa on neljä monimutkaista osiota. (Internetissä kukaan ei tiedä vanhaa sahaa huumorin analysoinnista ja sammakoiden leikkaamisesta.)

Hyvä uutinen on, että nimettömyys voi olla vapauttavaa ja hyödyllistä. Huono uutinen on, että meillä ei ole aavistustakaan siitä, miten tehdä muuta kuin nimetön viestintä. Jotkut ohjelmoijat puhuvat "kaksivaiheisesta todennuksesta", mutta älykkäät siirtyvät "N-tekijän todennukseen".

Salasanan ja ehkä matkapuhelimeen lähetetyn tekstiviestin jälkeen meillä ei ole paljoakaan vakautta. Sormenjälkilukijat näyttävät vaikuttavilta, mutta monet ihmiset näyttävät olevan halukkaita paljastamaan, miten niitä voidaan hakkeroida (katso täältä, täältä ja täältä aloittajilta).

Paljon tästä ei ole merkitystä Snapchatin tai Redditin joutokäynnin maailmalle, mutta hakkeroitujen Facebook-sivujen virta on hieman hämmentävä. Ei ole helppoa tapaa käsitellä vakavia asioita, kuten omaisuutta, rahaa, terveydenhuoltoa tai melkein kaikkea muuta elämässä, paitsi turhaa pikkupuhetta. Bitcoin-fanibobit rakastavat kiusata siitä, kuinka kova vankka lohkoketju voi olla, mutta jotenkin kolikot repeytyvät jatkuvasti (katso täällä ja täällä). Meillä ei ole todellista tapaa käsitellä identiteettiä.

Kovuuden mittaaminen

Tietenkin, onko ohjelmoinnissa edes tapa mitata ongelman vaikeus? Kukaan ei todellakaan tiedä. Tiedämme, että jotkut ongelmat on helppo ratkaista, mutta on täysin erilaista todistaa yksi kovaksi. NP-täydellisyys on vain yksi osa monimutkaista yritystä koodata algoritmien ja tietojen analysoinnin monimutkaisuus. Teoria on hyödyllinen, mutta se ei voi tarjota mitään takeita. On houkuttelevaa sanoa, että on vaikea edes tietää, onko ongelma vaikea, mutta no, saat vitsi.