Słoń w pokoju (w Kairze)
W programowaniu łatwo otrzeć się o nieskończoność. Wciąż nie wiemy, czy i kiedy maszyna Turinga się zatrzyma. Brak przecinka czy niezamknięty nawias może spowodować, że program wpadnie w nieskończoną pętlę, z której może się już nie wydostać.
Słoń w pokoju
Przed nieskończonością można się bronić na wiele sposobów. Jednym z nich jest wystawienie w kodzie strażnika. Tak zwana sentinel value to wartość używana jako sygnał dla programu do zakończenia pętli lub działania algorytmu.
Spróbujmy to przełożyć na realny przykład. Wyobraźmy sobie, że tworzymy prosty parser wiadomości. Żeby lepiej pokazać rolę sentinela, załóżmy, że parser czyta wiadomość znak po znaku w kółko i kończy pracę dopiero po napotkaniu znaku końca - w naszym przypadku jest to znak hasza (#).
W kodzie mogłoby to wyglądać tak:
def read_message(message):
sentinel = "#"
parsed = ""
index = 0
while True:
char = message[index % len(message)]
index += 1
print(f"Read: {char}")
# Comment out these three lines and the
# program will keep reading forever.
if char == sentinel:
print("\n[STOP] Sentinel reached.")
break
parsed += char
return parsed
message = "Hello World#"
print("\nParsed message:")
print(read_message(message))
Po uruchomieniu programu dostaniemy taki wynik:
Parsed message:
Read: H
Read: e
Read: l
Read: l
Read: o
Read:
Read: W
Read: o
Read: r
Read: l
Read: d
Read: #
[STOP] Sentinel reached.
Hello World
Jeśli wykomentujemy cały blok if, nasz program wpadnie w nieskończoną pętlę: będzie czytał ‘Hello Worlda’ znak po znaku aż nie padnie. W wersji ze strażnikiem skończy na pierwszym napotkanym haszu.
Jest tutaj jednak pewien haczyk. Kod z przykładu działa tylko dlatego, że hasz pojawia się w wiadomości dokładnie tam, gdzie się go spodziewamy — na końcu wiadomości. Gdyby w ogóle się nie pojawił, to program znowu utkwiłby w nieskończonej pętli.
A gdyby tak Hello Worlda zastąpić wiadomością, w której hasz byłby legitnym znakiem? Na przykład:
message = "John loves C# but he loves Python even more."
Dla takiej wiadomości program wypisze nam: John loves C. Nie wiem, co na to John, ale coś tu się popsuło. Sytuację należy rozpatrywać w kategoriach błędu programisty, który użył wieloznacznej wartości jako sentinela. Zatrudniony przez niego strażnik okazał się zbyt nadgorliwy i nie wpuścił na imprezę głównego gościa.
Z tego powodu wartość strażnicza powinna być wyjątkowa. Jeśli znak, który ma mieć specjalną rolę w programie, może pojawić się jako poprawna część danych (jak # w nazwie języka C#), to może to doprowadzić do nieoczywistych błędów.
Pamiętajcie więc, żeby na strażników wybierać naprawdę wyjątkowe i sprawdzone wartości.
Słoń w Kairze
A teraz wracamy do słonia w pokoju. Skąd w ogóle wziął się w Kairze? Co ma wspólnego z programowaniem?
Wzmianka o słoniu pojawiła się po raz pierwszy prawie 40 lat temu w magazynie “Byte”. Jego skan możecie znależć tutaj (w pdf strona 428, w czasopiśmie strona 404).
Peter C. Olsen opisał w artukule tam zamieszczonym, w jaki sposób przedstawiciele różnych profesji polują na słonie w Afryce. Programiści na przykład umieszczają najpierw słonia w Kairze, żeby mieć pewność, że ich algorytm na polowanie się zakończy - i to jest właśnie klasyczny przykład użycia sentinel value.
Po przetłumaczeniu na nasz rodzimy język wyglądało to tak:
Programiści polują na słonie, wykonując Algorytm A:
- Jedź do Afryki.
- Zacznij od Przylądka Dobrej Nadziei.
- Posuwaj się w kierunku północnym w uporządkowany sposób, przecinając kontynent na przemian na wschód i zachód.
- Podczas każdego przejścia:
- Złap każde napotkane zwierzę.
- Porównaj każde złapane zwierzę ze znanym ci słoniem.
- Zatrzymaj się, gdy stwierdzisz dopasowanie.
Doświadczeni programiści modyfikują Algorytm A przez umieszczenie słonia w Kairze, żeby mieć pewność, że algorytm się zatrzyma.
Programistom assemblera najwygodniej wykonuje się Algorytm A na czworakach.
Przedruk za “Byte”, 1989 (Volume 14, Number 9)
W ramach ćwiczenia stylistycznego spróbowałam wymyślić kilka specjalizacji z branży IT, które mogłyby się pojawić w artykule Olsena, gdyby pisał go dzisiaj.
Oto kilka pomysłów, które przyszły mi do głowy:
Scrum Master na ceremonii Sprint planningu wyznacza cel złapania słonia, a następnie przez 2 tygodnie pyta codziennie, o status złapnia zwierzęcia. Pod koniec Spritnu robi retrospektywę, aby omówić, dlaczego słoń nie został złapany.
DevOps stawia infrastrukturę do łapania słonia. Przy deploymencie okazuje się, że obraz słonia w kontenerze, nie zgadza się wersją słonia w Terraformie.
Vibe coder promptuje złapania słonia w nowym modelu. Po przepaleniu kilku milionów tokenów model generuje zdjęcie nosorożca z trąbą i 5 nogami.
CyberSecurity Engineer stawia zaporę na złapanie słonia. Słoń ją omija.
BI developer pisze query i zaznacza na dashboardzie aktualne położenie słoni. Kiedy udaje się we wskazane miejsca, słoni tam nie ma.
L1 Support zakłada tiket na złapanie słonia i przepina go na przypadkową osobę.
Śmieszno czy czerstwo? Anyway, wymyślcie swoje lepsze.
Od: peer@diku.dk (Peer Wandel Hansen)
. _.----~~~~~~~7
/ ~-..-~~--..--.
.'.'.' `.
.~ \
.' `.
. ( \
'. ) `.
' ( ~-.
\ ~-~~7
`. __.._ .'
~-.--~~ ~--. /
; .-~
( .~
`. .'
; ;
`. ` _
) ) / )
( _.-' .-' .'
`. ( ) /
7 _; < _/
\ / ~
\ /
`. __..-'
~