Spis rzeczy
Software
Ostatnio toczy się w buzzie wiee...eelka dyskusja o oprogramowaniu. Głos zabierają wielcy programiści i managerowie, więc mi tam trochę nawet niezręcznie się odzywać. Jakbym, jak w muzyce, rzępolił na gitarze, gdy tam zebrali się prawdziwi kompozytorzy-wykonawcy i koneserzy. Co prawda rzępoliłem czasem (zawsze! :-) tony, których wcześniej nie słyszałem, lub zdawałem sobie z nich sprawę ledwo mgliście, więc ciągle jakby improwizowałem. ... Mógłbym opowiadać bez końca, ale nie o mnie chodzi.
Myślę, że szanowne, doborowe towarzystwo mogłoby skolekcjonować listę wybitnych software'owych artystów.
Z pewnością rej w niej będą wodzić między innymi lub głównie autorzy języków komputerowych. Jednak samo stworzenie języka nie powinno wystarczyć, to inna kategoria. Powinni także wykazać się eleganckimi próbkami kodu. Z pewnością tak będzie prawie za każdym razem. Jednak nic mi nie wiadomo o takich próbkach w przypadku twórcy pięknego języka Forth - Charles H. Moore'a. Nie zrobił na mnie miłego wrażenia, gdy go spotkałem osobiście, słuchałem jego odczytu. Co prawda nie jestem pewny, czy czasem o wiele więcej uznania nie należy się Elizabeth D. Rather, która z Forth uczyniła dojrzały język, zamiast kupy macros. Czy ktoś z Was orientuje się dokładniej? (Przyjaźniłem się z entuzjastą i super-ekspertem Fortha, Dr Ting. Warto popatrzeć, co on pisze; co prawda był wpatrzony w Moore'a jak w obraz).
Z drugiej strony nie znam próbek Larry Walla, twórcy Perla, ale widzę aż nadto, że jest artystą.
Jak nie zarobiłem
Historii pod takim tytułem mógłbym podać więcej. W danym wypadku z pewnym kolegą-managerem pracowałem wcześniej przez około rok, jako konsultant, ale na więcej niż pełny wymiar godzin (jednak nigdy nie więcej niż 12h na dobę, z reguły 12h, i 7 dni w tygodniu :-); tak było przez jakieś 9 miesięcy, po czym pewien projekt wykonałem na zasadzie "flat rate"). Teraz chciał mnie zatrudnić znowu. Ponieważ trochę się go obawiałem, to zażyczyłem sobie, żeby kontrakt dokładnie opiewał co mam zrobić. Tymczasem on uparł się, żeby wstawić frazę o "best effort". Czyli, że będę pracował ze wszystkich sił, najlepiej jak tylko potrafię. Nawet pewien miły człowiek pomagał nam jako pośrednik, bardzo cierpliwie i rozsądnie. Firma tego człowieka dostałaby część projektu. Pracowałem z tym właścicielem firmy harmonijnie w przeszłości, nawet kilka dni u niego mieszkałem, w Santa Barbara (pięknie tam, i mimo południowego położenia - ciut chłodno, chłodniej niż w Silicon Valley). Nic z umowy z moim kolegą nie wyszło. Obaj, manager i ja, zaparliśmy się. Koniec.
Po czasie myślę, że mogłem wtedy podjąć jedną więcej próbę dogadania się. Należało projekt, nie taki znowu mały, rozbić na części, i ustalić harmonogram płacenia. Po każdej części musiałby mi zapłacić, i dopiero potem przystąpiłbym do następnej. (Poniewać wszystko długo trwało w ogromnej firmie managera, to prawdopodobnie wypłaciłby mi z góry więcej :-). Wtedy nie bałbym się frazy "best effort". Rozumiałoby się, że każda strona mogłaby zakończyć współpracę po dowolnym etapie, gdyby po którymś etapie była z drugiej strony niezadowolona.
Dlaczego mój kolega tak się uparł? Przecież znał mnie, wiedział, że pracuję intensywnie. Czasem w nocy robiliśmy sobie przerwę na drinka, udawaliśmy się do baru lub restauracji. Po czym on się rozkładał, jechał do domu, a ja wracałem do pracy. Nie miałoby sensu dla mnie zepsuć sobie dobrą opinię. Myślę, że zależało mu na słodkim uczuciu kontrolowaniu drugiego. Gdy poznaliśmy się, on był na samym dole drabiny managerskiej w swojej firmie. W czasie wspólpracy piął się w górę. Im wyżej był, tym trudniej było wspólpracować. Na początku co powiedziałem technicznie, tak było. Z czasem zaczął się "konsultować" z innymi, a w przypadku pewnego mojego większego pomysłu ponadto chciał nawet zwołać większe zebranie, żeby niby wszyscy razem by zdecydowali - bez sensu!
Potem miałem niepotrzebną mi, gorzką satysfakcję. Mój kolega do pracy, którą miałem wykonać, wynajął niewielką, ale całą zawodową firmę software'ową. Przez pewien czas był z nich zadowolony. Prawdziwi unixowcy, znają narzędzia, napisali śliczny kod, profesjonalnie, piękne indentacje, przyjemnie patrzeć. Tyle że kod dreptał w miejscu, nigdy niczego nie byl w stanie wyliczyć, bo zajmowało mu wieki i milenia. Projekt upadł.Nawet domyślałem się dlaczego ich oprogramnowanie ślamarzyło się, gdy moje kody fruwały. Prawdopodobnie używali unixowe narzędzia do tworzenia języków. Taki trade-off, bo łatwo się pisze, szybko, rekursyjnie, niewiele się samemu myśli, niewiele się samemu rozumie, bo OGÓLNY kod SAM wszystko wie za człowieka. Tylko, że kiedy kod wie wszystko, to nic nie wie o szybkości, zero. A w ambitnych, złożonych sytuacjach bez szybkości nie ma się niczego, nie ma o czym mówić, bo na wyniki programu trzeba czekać w grób-mogile po wieki. U mnie nazwa funkcji od razu funkcję wykonuje. U tych korzystaczy z narzędzi, gdy w programie występuje nazwa funkcji z zastosowania, to ich kompiler musi najpier tę funkcję rozpoznać, musi dokonać parsingu. U mnie użytkownik, wcale sobie z tego nie zdając sprawy :-), sam parsował machinalnie, a kompiler języka i komputer tylko program egzekwował. Przy symulacjach zawsze stosowałem ten bezpośredni styl. (Myślę, że wtedy programy użytkownika jest też bez porównania łatwiej użytkownikowi debuggować).
Kiedyś (nieco później), kiedy patrzyłem na budynek pewnej firmy biologicznej z okna mojego mieszkania - akurat miałem taki widok w niedalekiej oddali) to się uśmiechałem. Bowiem dla siebie, prywatnie, napisałem kod dla aminokwasów, i przyjemnie było patrzeć jak lata. A oni kod, robiący to samo, reklamowali, a nawet udostępniali publice. Zabawy z ich kodem było niewiele, bo ich marnując wiele czasu byl w stanie czasem rozwiązywać łancuchy długości do 5, może 7 symboli (chyyba nie :-). Myślę, że zgadłem powód, dla którego ich kod nie działał. Chodziło o optymizację. Wprowadza się w niej pewne wagi. Głowę dam, że oni "genialnie" (:-) rozpatrywali także wagi ujemne, nie rozumiejąc, że wtedy powstają nieskończone pętle. Zamiast czynić pewne wagi ujemnymi, należało zwiększyć pozostałe. Wtedy algorytm (programowanie dynamiczne) działałby jak ta lala.
Podejście do programnowania
Kolejne dzieci uczyłem jak programować gry w BASICu dla młodszych dzieci. Nie pamiętam, czy nauczyłem także najmłodszą, bo ona już nie miała komu programować. A przede wszystkim, mówiąc serio, sytuacja życiowa się zmieniała. W każdym razie jej brat, sam szkrab, programował dla niej od ręki, kiedy się nudziła. Program pytal ją jak ma na imię, potem zwracał się do niej po imieniu. Ona miała pomyśleć sobie liczbę, a program liczbę zgadywał, dzieląc przedział na pół, pytając ją czy już, czy też ma iść w górę lub w dół. Dziecku było przyjemnie grać.
Podobny porogram napisał mój kolega w pracy, inżynier-manager, dla swojej córki. Program robił na ekranie wrażenie niesprzątneitej hali fabrycznej w porwnaniu ze schludnym, wygodnym mieszkanie. Nic koledze nie powiedziałem, nie miałem serca, gdy przecież tak się dla swojego dziecka postarał (w pracy byłem dla niego znacznie ostrzejszy, mimo że był formalnie moim bosem). Oczywiście poprawiłbym mu programik, ale przecież nie mogłem ingerować w życie rodzinne kolegi, itd.
To jest moja odpowiedź - przynajmniej metafora - na pytanie o znaczenie zwrotu "życia programowaniem". Bo nie chodzi akurat o "user interface", tylko o podejście w każdym wymiarze. (W środku kod mojego szkraba-syna też ładniej wyglądał, niż kolegi. Dlatego może po latach syn, prawie bez formalnego wykształcenia, dawał odczyty na konferencjach, i bardzo ładnie zarabiał, ucząc w firmach programowania).
No comments:
Post a Comment