Zgubna automatyzacja na przykładzie HelloBota
Co się stanie z lekarzem, który popełni błąd? Może trafić do więzienia. Co się stanie z urzędnikiem, który popełni błąd? Może dostać premię. Co się stanie z programistą, który popełni błąd?
Jesteśmy jako społeczeństwo dość uzależnieni od automatów i innych "ułatwiaczy", nawet jak są one kompletnie zbędne jak elektryczne otwieranie szyb (by nie trzeba było kręcić korbką w samochodzie). Nie jest to oczywiście złe rozwiązanie, ale idziemy coraz częściej w kierunku ułatwiania sobie życia.
Parę dni temu jak wiecie - skrypt HelloBota nie zadziałał (co się czasem zdarza, ale wiadomo :D). Można było zrzucić wszystko na sieć Steem, ale to nie był w tym problem (tym razem :D). Problemem był błąd człowieka (czyli mój) spowodowany przez ułatwianie i automatyzację wszystkiego co się da zautomatyzować.
Czy 3 == "3"?
W starych językach programowania jak w C++ na początku kodu (zwykle) deklaruje się typ zmiennej i samą zmienną. Dana zmienna (taka szufladka) może przechowywać różne dane - zwykle liczby albo tekst. W starym kodzie zwykle się ustawiało, że dana zmienna przechowuje liczby.
W językach nowszych jak PHP zwykle się tego nie robi, kompilator / interpreter sam się domyśla. Oczywiście czasem robi to źle i człowiek musi to skorygować.
Ale po kolei
OpenWeatherMap
HelloBot naturalnie pobiera różne rzeczy z różnych baz danych, pogoda idzie z OpenWeatherMap, która jest darmowa (wbrew pozorom takie dane często są płatne). Zdarzało się jednak, że z jakiegoś nieznanego powodu niektóre pomiary zwracały 0. Nie 0 stopni Celsjusza, tylko 0. Co z fantem zrobić? Przypadki nie były spowodowane awariami, więc powstał kod, który sprawdzał jaka jest temperatura i jeśli temperatura wynosiła 0 to program jeszcze raz dla danego miasta pobierał temperaturę - zwykle poprawną.
I działało wszystko
6 Marca 2018 roku
Dzień jak co dzień. Wstaję rano sprawdzić czy HelloBot działa - i wpisu nie ma. Trudno, odpalę ręcznie bota ... błędy, dużo błędów z OpenWeatherMap. Wchodzę na maila, a tam ... blokada konta. Według OWM w ciągu minuty wysłałem kilkaset próśb o pobranie pogody podczas gdy darmowe konta mogą mieć takich zapytań 60. Ale co się stało, przecież pobieram dane z 16 miast.
Wszystko sprowadzało się do felernego kodu o którym wspomniałem wcześniej i automatu. Kod sprawdzał czy zwracana wartość jest równa 0. Ale 6 Marca to dzień, w którym temperatury rosły i w niektórych miastach były równe 0 stopni Celsjusza. Automat oczywiście zamienił "0 *C" na 0 ... A jako, że "zero to zero" to skrypt poprosił o pobranie temperatury ponownie ... i znowu zero. No to ponownie (...).
Powstał HelloBotgeddon.
Czy automaty są fajne?
HelloBot to najlepsza rzecz na świecie. Ale nie o niego tu chodzi ;) Podstawowym zadaniem ludzi powinno być "ufam, ale sprawdzam" - od programistów po nawet pilotów lotniczych. Mimo wszystko jednak cała technologia idzie w kierunku automatyzacji a nie wspomagania, jako, że dobrze napisany program może być bezpieczniejszy od człowieka. Ale czy umiemy pisać dobre programy? Jeden błąd nie doprowadził do katastrofy Steemowej i pamiętajmy o tym opowiadając tę historię wnukom za 40 lat.
Ogólnie nigdy wszystkiego nie przewidzicie, gdyż błądzenie jest rzeczą ludzką. Czy zatem lekarze popełniający błędy powinni odpowiadać karnie za błędy? Ciekawa kwestia.
Wymieszałeś równo trzy cechy języków programowania - wiek, typizację i deklaracje zmiennych. Nieprawdą jest, że w starych językach zmienne musiały być zadeklarowane, albo miały statyczny typ. Już Fortran (rocznik 1957) obywał się bez deklaracji zmiennych, a Lisp (1958) miał dynamiczną typizację. To są dwa najstarsze używane do dzisiaj języki programowania wysokiego poziomu. Dynamiczna typizacja wywodzi się właśnie z Lispa, podobnie jak odśmiecanie pamięci.
Ze zgred(k)owskim pozdrowieniem :)
Być może, nigdy nie interesowałem się fortanem czy lispem. ;)
Automaty są fajne, ale tylko wtedy, kiedy robią swoją robotę. Kompilator czy interpreter, który "domyśla się" robiąc de facto po swojemu, zamiast słuchać rozkazów, to nie jest fajny automat, tylko 💩, którego nie da się używać...
Pierwsza zasada pracy w mojej branży - elektronika bywa zawodna. Teoria ta potwierdza się również w życiu codziennym. Kilkakrotnie byłem świadkiem jak przy otwartych rogatkach na przejeździe kolejowym pojawiał się pociąg... Zawsze zwalniam przed otwartymi przejazdami i rozglądam się czy nie nadjeżdża pociąg. Zdarza się, że jadący za mną trąbią... Mam na to wyje#@%^$! Ufam, że podniesione rogatki oznaczają bezpieczny przejazd... ale sprawdzam... Elektronika bywa zawodna.
Skutki uboczne projektowanego systemu, to największa zmora projektanta. Tu potrzebne są jakieś procedury branżowe.
To też jest zagadnienie bardzo szerokie. Takie państwa jak Niemcy (hitleryzm) Rosja, (bolszewizm) -historycznie wykazywały niefrasobliwość, przy instalacji twardych systemów, a skutki uboczne skumulowały im się tragicznie.
I tak może być w wielu innych systemach zautomatyzowanych. Zatem kwestie skutków ubocznych zawsze musimy oswajać, wręcz paranoicznie, aby zapobiegać katastrofie (mimo że gwarancji nie ma).
O problemach automatyzacji piszą tutaj, choć w trochę innych aspektach, ale warto te tematy eksplorować i rozdziewiczać nieznane.
Dlatego z przyzwyczajenia z cpp, zawsze deklaruję zmienne. :D
A co do ostatniego pytania: Lekarze powinni odpowiadać prawnie, jeśli wiedzą, że spieprzyli, a kłamią o dobrym stanie zdrowia i ukrywają błędy.
To ciekawy temat, ale no... jaka praca - takie ryzyko.
Nauczyciel prawnie odpowiada za uczniów, lekarz za pacjentów, a kierowca za pasażerów. Normalne - taki zawód wybrali.
Testy. Piszmy testy :D Dawajmy wszystkie możliwe opcje i obsługujmy wszystkie błędy.