Między literaturą a programowaniem

Uwaga, w środku grasuje "ostateczny renderer ultymatywnej zagłady"!

 

Kod programu może być bezpieczny, szybko działać lub być czytelny. Te możliwości wykluczają się wzajemnie. Na przykład w wariancie bezpiecznym umieszcza się dodatkowe instrukcje sprawdzające, czy sposób użycia jest zgodny z zamierzeniami programisty. W programie sumowania dwóch liczb można upewnić się, czy obydwie zostały podane (choć można było przyjąć, że brak oznacza zero). Realne instrukcje sprawdzające są bardziej złożone a ich wykonanie zabierze odczuwalny czas oraz powiększy kod źródłowy, czyniąc go mniej czytelnym.

Świadomie lub nie, każdy programista wybiera swoje miejsce w tym trójkątnym układzie współrzędnych. Tak jak w życiu, tutaj też ortodoksów jest niewiele a najbardziej popularny jest środek, czyli styl trochę niebezpieczny, trochę wolny i trochę nieczytelny. Bardziej odczuwalne jest połączenie częściowych wad niż częściowych zalet. Osobiście wolę mieć samochód, który ma niezwykły komfort jazdy ale niezwykle słabo jeździ, niż taki w którym będę narzekał i na komfort jazdy i na osiągi.

Wybór stylu programowania jest w jakiś zagadkowy sposób połączony z cechami charakteru. Nie znam precyzyjnych reguł tego odwzorowania. Kusi proste założenie, że jeśli programista ma drzwi z pięcioma zamkami i dwa psy nauczone z wyraźnym ożywieniem reagować na polecenie "bierz go", to wybierze styl bezpieczny. Ale być może kod będzie jego odskocznią, jedynym miejscem gdzie będzie ryzykantem, renegatem informatyki, człowiekiem-błędem? Zagadkowa ale więź stylu z psyche istnieje - widzę to po swoich wyraźnych sympatiach: nie przepadam za osobami które programują bezpiecznie (szczególnie “paranoików bezpieczeństwa”), dogaduję się z autorami szybkiego kodu a przepadam za maniakami czytelności.

Jednak niezależnie od stylu pisania, każdy program będzie się czasem psuł, zwalniał i wymagał pracy w utrzymaniu. Być może dla samego programu ten podział na sposoby pisania nie ma znaczenia, tak długo jak jest obecny zaangażowany zespół! Możemy więc rozważyć alternatywne sposoby pisania, nowe kierunki, które będą przede wszystkim sprawiać przyjemność programistom.

Proponuję więc pisać wierszem. Zapytanie SQL może przecież mieć postać:

select one, nice, girl
from girls, that will
join me once
join me twice
join me forever

To tylko szybko napisany wiersz biały. Myślę, że przy odrobinie wysiłku programistyczne pętle, warunki i tablice zamienią się w przerzutnie, metafory oraz teksty dźwiękonaśladowcze. Jest ogromny transcendentalny potencjał w słowach języka programowania "Void" (pustka), "przepełnienie bufora", "warunek graniczny", "pusty wskaźnik" - przecież te informatyczne terminy to druga mitologia! A ponieważ są to jednocześnie działające programy, to ich funkcjonalność jest dodatkową warstwą tej gry. Szokujący może być poemat o nieskończonej miłości, który jako program wpada w nieskończoną pętle.

Pamiętam też fragment programu, który chociaż został napisany z mniejszym rozmachem, to powstał autentycznie i działa do dziś. Dotyczył programu w którym prowadziłem refaktoryzację (wspaniałe dźwiękonaśladowcze słowo oznaczające uproszczenie wyglądu kodu bez zmiany funkcjonalności programu). W kodzie był mały fragment o postaci mniej więcej:

renderer1=new HtmlRenderer();
renderer2=new HtmlRenderer();
renderer2.parse(…)

- O rany, jak tutaj nadać jakieś bardziej opisowe nazwy w miejsce renderer1 i renderer2?
- A potrzebujemy dwóch zmiennych?
- Niestety tak
- Ale zauważ, że ten wybór nie ma dużego znaczenia, bo funkcja jest mała a to tylko zmienne lokalne dla niej
- Czyli możemy nazwać dowolnie?
- Tak, dowolnie
- To ja chcę zamiast renderer2 nazwę “finalRendererOfUltimateDoom” (ostateczny renderer ultymatywnej zagłady)

 

 

 

A więc zrefaktoryzowaliśmy:

renderer1=new HtmlRenderer();
finalRendererOfUltimateDoom=new (...);
finalRendererOfUltimateDoom.parse(…)

Pisanie kodu, który jest jednocześnie programem i literaturą kojarzy mi się z “literate programming”, choć Don Knuth (autor tego pomysłu) nie miał na myśli wierszy ale czytelność tekstu dorównującą mowie naturalnej:

Wikipedia:
Literate programming (ang. programowanie piśmienne) to styl programowania oparty na założeniu, że programy komputerowe powinny być pisane z naciskiem na czytelność kodu źródłowego dla ludzi, podobnie do dzieła literackiego. Najważniejsza staje się dokumentacja dokładnie tłumacząca działanie algorytmu, w którą dopiero wplecione są fragmenty w języku programowania. Kontrastuje z powszechnym poglądem, że głównym celem jest stworzenie działającego kodu, którego dokumentacja pełni rolę pomocniczą.

Programowanie w ten sposób polega na zapisaniu co robi program po czym napisanie interpretera tych zdań. Są dwa warunki a) zdania muszą być zapisane mową na tyle potoczną i naturalną na ile jest to możliwe ... b) ale jednocześnie na tyle w usystematyzowany sposób, że będzie możliwe napisanie interpretera. Ogólna idea literate programming polega właśnie na tym, że aby napisać czytelną aplikację wymyśla się dopasowany do niej nowy system wypowiedzi (właściwie język programowania)

Ach jak pięknie byłoby napisać aplikację heksametrem.

 

 

  1. Pisałem o programach, które są poezją, tutaj natomiast jest poezja o programowaniu.
  2. Temat na zupełnie inny artykuł
  3. Firma, która do dziś używa ostatecznego renderera ultymatywnej zagłady
  4. Tekst o nieustającej rywalizacji pomiędzy Postludzkimi Inteligencjami, a Inkluzjami Ultymatywnymi.
  5. Archiwum moich tekstów.
Maciek Kapustka

Maciek Kapustka

38 lat Warszawa
2 artykuły 22 teksty 33 komentarze


Dodaj komentarz anonimowo lub zaloguj się
 
przysłano: 9 grudnia 2009 (historia)


Strona korzysta z plików cookie w celu realizacji usług zgodnie z Polityką prywatności.
Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce.

Zgłoś obraźliwą treść

Uzasadnij swoje zgłoszenie.

wpisz wiadomość


lub tradycyjnie
login lub email
hasło