Pokonując średnią
Chcesz założyć startup? Zdobądź finansowanie od Y Combinator.
Kwiecień 2001, rew. kwiecień 2003
(Ten artykuł pochodzi z prezentacji wygłoszonej na Franz Developer Symposium w 2001 roku.)
W lecie 1995 roku mój przyjaciel Robert Morris i ja założyliśmy startup o nazwie Viaweb. Naszym planem było napisanie oprogramowania, które pozwoliłoby użytkownikom końcowym tworzyć sklepy internetowe. Nowością w tym oprogramowaniu była wówczas jego praca na naszym serwerze, z wykorzystaniem zwykłych stron internetowych jako interfejsu.
Oczywiście wiele osób mogło wpaść na ten sam pomysł w tym samym czasie, ale o ile mi wiadomo, Viaweb było pierwszą aplikacją opartą na sieci Web. Wydawało nam się to tak nowatorskim pomysłem, że nazwaliśmy firmę na jego cześć: Viaweb, ponieważ nasze oprogramowanie działało poprzez sieć Web, zamiast działać na komputerze stacjonarnym użytkownika.
Inną niezwykłą rzeczą w tym oprogramowaniu było to, że zostało ono napisane głównie w języku programowania zwanym Lisp. Była to jedna z pierwszych dużych aplikacji dla użytkowników końcowych napisanych w Lisp, który do tej pory był używany głównie na uniwersytetach i w laboratoriach badawczych.[1]
Tajny Bron
Eric Raymond napisał esej zatytułowany „Jak zostać hakerem”, w którym między innymi radzi przyszłym hakerom, jakich języków powinni się uczyć. Sugeruje zacząć od Pythona i Javy, ponieważ są łatwe do nauczenia. Poważny haker będzie również chciał nauczyć się C, aby hakować Uniksa, i Perla do administracji systemem i skryptów cgi. Wreszcie, prawdziwie poważny haker powinien rozważyć naukę Lispa:
Lisp jest wart nauki ze względu na głębokie doświadczenie oświecenia, które będziesz miał, gdy w końcu go zrozumiesz; to doświadczenie sprawi, że będziesz lepszym programistą przez resztę swoich dni, nawet jeśli nigdy nie będziesz faktycznie dużo używać samego Lispa.
To ten sam argument, który słyszy się w przypadku nauki łaciny. Nie zdobędziesz dzięki niej pracy, być może z wyjątkiem stanowiska profesora filologii klasycznej, ale poprawi ona twój umysł i sprawi, że będziesz lepszym pisarzem w językach, których chcesz używać, takich jak angielski.
Ale chwileczkę. Ta metafora nie rozciąga się tak daleko. Powodem, dla którego łacina nie zapewni ci pracy, jest to, że nikt jej nie mówi. Jeśli piszesz po łacinie, nikt cię nie zrozumie. Ale Lisp jest językiem komputerowym, a komputery mówią w każdym języku, w którym im powiesz, programisto.
Więc jeśli Lisp czyni cię lepszym programistą, jak mówi, dlaczego nie chciałbyś go używać? Gdyby malarzowi zaoferowano pędzel, który uczyniłby go lepszym malarzem, wydaje mi się, że chciałby go używać we wszystkich swoich obrazach, prawda? Nie próbuję tu wyśmiewać Erica Raymonda. Ogólnie rzecz biorąc, jego rady są dobre. To, co mówi o Lisp, jest w dużej mierze konwencjonalną mądrością. Ale w konwencjonalnej mądrości jest sprzeczność: Lisp uczyni cię lepszym programistą, a jednak go nie użyjesz.
Dlaczego nie? Języki programowania to przecież tylko narzędzia. Jeśli Lisp faktycznie daje lepsze programy, powinieneś go używać. A jeśli nie, to kto go potrzebuje?
To nie jest tylko pytanie teoretyczne. Oprogramowanie to bardzo konkurencyjny biznes, podatny na naturalne monopole. Firma, która pisze oprogramowanie szybciej i lepiej, przy wszystkich innych równych warunkach, wyeliminuje swoich konkurentów z rynku. A kiedy zakładasz startup, czujesz to bardzo mocno. Startupy zazwyczaj są propozycją „wszystko albo nic”. Albo się wzbogacisz, albo nic nie dostaniesz. W startupie, jeśli postawisz na złą technologię, twoi konkurenci cię zmiażdżą.
Robert i ja dobrze znaliśmy Lispa i nie widzieliśmy powodu, by nie ufać naszym instynktom i nie wybrać Lispa. Wiedzieliśmy, że wszyscy inni piszą swoje oprogramowanie w C++ lub Perlu. Ale wiedzieliśmy też, że to nic nie znaczy. Jeśli wybierasz technologię w ten sposób, będziesz używać Windowsa. Wybierając technologię, musisz zignorować to, co robią inni, i rozważyć tylko to, co zadziała najlepiej.
Jest to szczególnie prawdziwe w startupie. W dużej firmie możesz robić to, co robią wszystkie inne duże firmy. Ale startup nie może robić tego, co robią wszystkie inne startupy. Nie sądzę, żeby wiele osób sobie z tego zdawało sprawę, nawet w startupach.
Przeciętna duża firma rośnie o około dziesięć procent rocznie. Więc jeśli prowadzisz dużą firmę i robisz wszystko tak, jak robi to przeciętna duża firma, możesz oczekiwać, że osiągniesz wyniki porównywalne z przeciętną dużą firmą – to znaczy, że będziesz rósł o około dziesięć procent rocznie.
To samo stanie się oczywiście, jeśli prowadzisz startup. Jeśli robisz wszystko tak, jak robi to przeciętny startup, powinieneś oczekiwać przeciętnych wyników. Problem polega na tym, że przeciętne wyniki oznaczają, że zbankrutujesz. Wskaźnik przeżywalności startupów jest znacznie poniżej pięćdziesięciu procent. Więc jeśli prowadzisz startup, lepiej robisz coś dziwnego. Jeśli nie, jesteś w kłopotach.
W 1995 roku wiedzieliśmy coś, czego, jak sądzę, nasi konkurenci nie rozumieli, a niewielu rozumie nawet dzisiaj: kiedy piszesz oprogramowanie, które musi działać tylko na twoich własnych serwerach, możesz użyć dowolnego języka. Pisząc oprogramowanie na komputery stacjonarne, istnieje silna tendencja do pisania aplikacji w tym samym języku, co system operacyjny. Dziesięć lat temu pisanie aplikacji oznaczało pisanie aplikacji w C. Ale dzięki oprogramowaniu opartemu na sieci Web, zwłaszcza gdy masz kod źródłowy zarówno języka, jak i systemu operacyjnego, możesz używać dowolnego języka.
Ta nowa wolność jest jednak mieczem obosiecznym. Teraz, gdy możesz używać dowolnego języka, musisz pomyśleć, który wybrać. Firmy, które próbują udawać, że nic się nie zmieniło, ryzykują, że ich konkurenci tego nie zrobią.
Jeśli możesz używać dowolnego języka, którego używasz? My wybraliśmy Lispa. Po pierwsze, było oczywiste, że szybki rozwój będzie ważny na tym rynku. Wszyscy zaczynaliśmy od zera, więc firma, która mogłaby wprowadzić nowe funkcje przed konkurencją, miałaby dużą przewagę. Wiedzieliśmy, że Lisp jest naprawdę dobrym językiem do szybkiego pisania oprogramowania, a aplikacje serwerowe potęgują efekt szybkiego rozwoju, ponieważ możesz wydać oprogramowanie w chwili, gdy jest gotowe.
Jeśli inne firmy nie chciały używać Lispa, tym lepiej. Mogło to dać nam przewagę technologiczną, a my potrzebowaliśmy wszelkiej możliwej pomocy. Kiedy zaczynaliśmy Viaweb, nie mieliśmy doświadczenia w biznesie. Nie wiedzieliśmy nic o marketingu, zatrudnianiu ludzi, pozyskiwaniu funduszy ani zdobywaniu klientów. Żadne z nas nigdy nawet nie miało czegoś, co można by nazwać prawdziwą pracą. Jedyną rzeczą, w której byliśmy dobrzy, było pisanie oprogramowania. Mieliśmy nadzieję, że to nas uratuje. Każdej przewagi, jaką mogliśmy uzyskać w dziale oprogramowania, byśmy skorzystali.
Można więc powiedzieć, że użycie Lispa było eksperymentem. Nasza hipoteza była taka, że jeśli napiszemy nasze oprogramowanie w Lisp, będziemy w stanie szybciej niż nasi konkurenci wprowadzać funkcje, a także robić w naszym oprogramowaniu rzeczy, których oni nie mogli. A ponieważ Lisp był tak wysokopoziomowy, nie potrzebowalibyśmy dużego zespołu programistów, więc nasze koszty byłyby niższe. Jeśli tak by było, moglibyśmy zaoferować lepszy produkt za mniejsze pieniądze i nadal zarabiać. Skończyłoby się na tym, że zdobylibyśmy wszystkich użytkowników, a nasi konkurenci nie zdobyliby nikogo i ostatecznie zbankrutowaliby. Tego właśnie się spodziewaliśmy, w każdym razie.
Jakie były wyniki tego eksperymentu? Co zaskakujące, zadziałało. Mieliśmy ostatecznie wielu konkurentów, rzędu dwudziestu do trzydziestu, ale żaden z ich programów nie mógł konkurować z naszym. Mieliśmy edytor sklepów internetowych wysiwyg, który działał na serwerze, a jednocześnie przypominał aplikację desktopową. Nasi konkurenci mieli skrypty cgi. I zawsze byliśmy od nich znacznie lepsi pod względem funkcji. Czasami, w desperacji, konkurenci próbowali wprowadzać funkcje, których my nie mieliśmy. Ale dzięki Lisp nasz cykl rozwoju był tak szybki, że czasami mogliśmy zduplikować nową funkcję w ciągu dnia lub dwóch od ogłoszenia jej przez konkurencję w komunikacie prasowym. Zanim dziennikarze relacjonujący komunikat prasowy zdążyli do nas zadzwonić, mieliśmy już tę nową funkcję.
Naszym konkurentom musiało się wydawać, że mamy jakąś tajną broń – że rozszyfrowujemy ich ruch Enigmy czy coś w tym stylu. W rzeczywistości mieliśmy tajną broń, ale była ona prostsza, niż sobie wyobrażali. Nikt nie wykradał nam wiadomości o ich funkcjach. Po prostu byliśmy w stanie rozwijać oprogramowanie szybciej, niż ktokolwiek uważał za możliwe.
Mając około dziewięciu lat, przypadkiem zdobyłem egzemplarz „Szakala” Fredericka Forsytha. Główny bohater to zabójca, który zostaje wynajęty do zabicia prezydenta Francji. Zabójca musi ominąć policję, aby dostać się do mieszkania z widokiem na trasę prezydenta. Przechodzi tuż obok nich, przebrany za starego człowieka o kulach, a oni nigdy go nie podejrzewają.
Nasza tajna broń była podobna. Nasze oprogramowanie napisaliśmy w dziwnym języku AI, z dziwną składnią pełną nawiasów. Przez lata drażniło mnie, gdy Lisp był tak opisywany. Ale teraz działało to na naszą korzyść. W biznesie nie ma nic cenniejszego niż przewaga techniczna, której twoi konkurenci nie rozumieją. W biznesie, podobnie jak na wojnie, zaskoczenie jest warte tyle samo co siła.
I tak, muszę to powiedzieć z pewnym zażenowaniem, nigdy publicznie nie mówiłem nic o Lisp podczas pracy nad Viaweb. Nigdy nie wspominaliśmy o tym prasie, a jeśli szukałeś Lispa na naszej stronie internetowej, znalazłbyś tylko tytuły dwóch książek w moim biogramie. To nie był przypadek. Startup powinien dostarczać swoim konkurentom jak najmniej informacji. Jeśli nie wiedzieli, w jakim języku napisano nasze oprogramowanie, lub nie dbali o to, ja chciałem, żeby tak pozostało.[2]
Ludzie, którzy najlepiej rozumieli naszą technologię, to byli klienci. Oni też nie przejmowali się tym, w jakim języku napisano Viaweb, ale zauważyli, że działa naprawdę dobrze. Pozwalało im to tworzyć świetnie wyglądające sklepy internetowe dosłownie w kilka minut. I tak, głównie dzięki poczcie pantoflowej, zdobywaliśmy coraz więcej użytkowników. Pod koniec 1996 roku mieliśmy około 70 sklepów online. Pod koniec 1997 roku mieliśmy ich 500. Sześć miesięcy później, kiedy kupiło nas Yahoo, mieliśmy 1070 użytkowników. Dziś, jako Yahoo Store, to oprogramowanie nadal dominuje na swoim rynku. Jest to jeden z bardziej dochodowych elementów Yahoo, a sklepy zbudowane przy jego użyciu stanowią podstawę Yahoo Shopping. Opuściłem Yahoo w 1999 roku, więc nie wiem dokładnie, ilu użytkowników mają teraz, ale ostatnio słyszałem, że jest ich około 20 000.
Paradoks Bluba
Co jest tak wspaniałego w Lisp? A jeśli Lisp jest tak wspaniały, dlaczego nie wszyscy go używają? Brzmi to jak pytania retoryczne, ale w rzeczywistości mają proste odpowiedzi. Lisp jest tak wspaniały nie z powodu jakiejś magicznej cechy widocznej tylko dla wyznawców, ale dlatego, że jest po prostu najpotężniejszym dostępnym językiem. A powodem, dla którego nie wszyscy go używają, jest to, że języki programowania to nie tylko technologie, ale także nawyki umysłowe, a nic nie zmienia się wolniej. Oczywiście, obie te odpowiedzi wymagają wyjaśnienia.
Zacznę od szokująco kontrowersyjnego stwierdzenia: języki programowania różnią się mocą.
Przynajmniej niewielu zaprzeczyłoby, że języki wysokiego poziomu są potężniejsze niż język maszynowy. Większość programistów dzisiaj zgodziłaby się, że zazwyczaj nie chcesz programować w języku maszynowym. Zamiast tego powinieneś programować w języku wysokiego poziomu, a kompilator powinien go przetłumaczyć na język maszynowy. Ta idea jest nawet wbudowana w sprzęt: od lat 80. zestawy instrukcji są projektowane dla kompilatorów, a nie dla programistów.
Każdy wie, że błędem jest pisanie całego programu ręcznie w języku maszynowym. Mniej często rozumiane jest to, że istnieje tu bardziej ogólna zasada: że jeśli masz wybór kilku języków, to przy wszystkich innych równych warunkach, błędem jest programowanie w czymkolwiek innym niż najpotężniejszy.
Istnieje wiele wyjątków od tej reguły. Jeśli piszesz program, który musi ściśle współpracować z programem napisanym w określonym języku, dobrym pomysłem może być napisanie nowego programu w tym samym języku. Jeśli piszesz program, który musi tylko wykonywać bardzo proste zadanie, takie jak obliczenia numeryczne lub manipulacja bitami, możesz równie dobrze użyć mniej abstrakcyjnego języka, zwłaszcza że może być on nieco szybszy. A jeśli piszesz krótki, jednorazowy program, możesz lepiej po prostu użyć dowolnego języka, który ma najlepsze funkcje biblioteczne do danego zadania. Ale ogólnie rzecz biorąc, w przypadku oprogramowania aplikacyjnego, chcesz używać najpotężniejszego (rozsądnie wydajnego) języka, jaki możesz uzyskać, a używanie czegokolwiek innego jest błędem, dokładnie tego samego rodzaju, choć być może w mniejszym stopniu, co programowanie w języku maszynowym.
Możesz zauważyć, że język maszynowy jest bardzo niskopoziomowy. Ale, przynajmniej jako rodzaj konwencji społecznej, języki wysokiego poziomu są często traktowane jako równoważne. Nie są. Technicznie rzecz biorąc, termin „język wysokiego poziomu” niczego bardzo konkretnego nie oznacza. Nie ma linii podziału z językami maszynowymi po jednej stronie i wszystkimi językami wysokiego poziomu po drugiej. Języki znajdują się w continuum [4] abstrakcji, od najpotężniejszych aż po języki maszynowe, które same w sobie różnią się mocą.
Rozważmy Cobol. Cobol jest językiem wysokiego poziomu w tym sensie, że jest kompilowany do języka maszynowego. Czy ktoś poważnie twierdziłby, że Cobol jest równoważny w mocy, powiedzmy, Pythonowi? Jest prawdopodobnie bliższy językowi maszynowemu niż Python.
Albo jak z Perlem 4? Między Perlem 4 a Perlem 5 do języka dodano domknięcia leksykalne. Większość hakerów Perla zgodziłaby się, że Perl 5 jest potężniejszy niż Perl 4. Ale gdy już to przyznasz, przyznajesz, że jeden język wysokiego poziomu może być potężniejszy od drugiego. I nieuchronnie wynika z tego, że z wyjątkiem szczególnych przypadków powinieneś używać najpotężniejszego, jaki możesz uzyskać.
Ta idea jest jednak rzadko doprowadzana do końca. Po pewnym wieku programiści rzadko dobrowolnie zmieniają języki. Jakiegokolwiek języka ludzie są przyzwyczajeni, mają tendencję uważać za wystarczający.
Programiści bardzo przywiązują się do swoich ulubionych języków i nie chcę nikogo urazić, więc aby wyjaśnić ten punkt, użyję hipotetycznego języka o nazwie Blub. Blub znajduje się dokładnie pośrodku kontinuum abstrakcji. Nie jest to najpotężniejszy język, ale jest potężniejszy niż Cobol czy język maszynowy.
A w rzeczywistości nasz hipotetyczny programista Blub nie używałby żadnego z nich. Oczywiście nie programowałby w języku maszynowym. Do tego służą kompilatory. A co do Cobola, to nie wie, jak można dzięki niemu cokolwiek zrobić. Nie ma nawet x (funkcja Bluba do wyboru).
Dopóki nasz hipotetyczny programista Blub patrzy w dół kontinuum mocy, wie, że patrzy w dół. Języki mniej potężne niż Blub są oczywiście mniej potężne, ponieważ brakuje im jakiejś funkcji, do której jest przyzwyczajony. Ale kiedy nasz hipotetyczny programista Blub patrzy w drugą stronę, w górę kontinuum mocy, nie zdaje sobie sprawy, że patrzy w górę. Widzi tylko dziwne języki. Prawdopodobnie uważa je za mniej więcej równoważne Blubowi pod względem mocy, ale z całym tym innym, trudnym do zrozumienia dodatkiem. Blub jest dla niego wystarczająco dobry, ponieważ myśli w Blub.
Kiedy jednak zmieniamy perspektywę na programistę używającego któregokolwiek z języków wyżej w kontinuum mocy, okazuje się, że on z kolei patrzy z pogardą na Bluba. Jak można cokolwiek zrobić w Blub? Nie ma nawet y.
Przez indukcję, jedynymi programistami, którzy są w stanie dostrzec wszystkie różnice w mocy między różnymi językami, są ci, którzy rozumieją najpotężniejszy. (To prawdopodobnie miał na myśli Eric Raymond, mówiąc, że Lisp czyni cię lepszym programistą.) Nie można ufać opiniom innych, ze względu na paradoks Bluba: są zadowoleni z dowolnego języka, którego akurat używają, ponieważ dyktuje on sposób, w jaki myślą o programach.
Wiem to z własnego doświadczenia, jako nastolatek piszący programy w Basic. Ten język nawet nie obsługiwał rekurencji. Trudno sobie wyobrazić pisanie programów bez używania rekurencji, ale wtedy jej nie brakowało. Myślałem w Basic. I byłem w tym świetny. Pan wszystkiego, co widziałem.
Pięć języków, które Eric Raymond poleca hakerom, znajduje się w różnych punktach kontinuum mocy. Gdzie się znajdują względem siebie, to delikatny temat. Powiem tylko, że moim zdaniem Lisp jest na szczycie. A aby poprzeć to twierdzenie, opowiem o jednej z rzeczy, których brakuje mi, gdy patrzę na pozostałe cztery języki. Jak można w nich cokolwiek zrobić, myślę, bez makr?[5]
Wiele języków ma coś, co nazywa się makrem. Ale makra Lispa są unikalne. I wierzcie lub nie, to, co robią, jest związane z nawiasami. Projektanci Lispa nie umieścili wszystkich tych nawiasów w języku tylko po to, by być innym. Dla programisty Bluba kod Lispa wygląda dziwnie. Ale te nawiasy są tam z jakiegoś powodu. Są zewnętrznym dowodem fundamentalnej różnicy między Lispa a innymi językami.
Kod Lispa jest tworzony z obiektów danych Lispa. I to nie w trywialnym sensie, że pliki źródłowe zawierają znaki, a ciągi znaków są jednym z typów danych obsługiwanych przez język. Kod Lispa, po odczytaniu przez parser, składa się ze struktur danych, które można przeszukiwać.
Jeśli rozumiesz, jak działają kompilatory, to tak naprawdę nie chodzi o to, że Lisp ma dziwną składnię, ale o to, że Lisp nie ma składni. Piszesz programy w drzewach parsowania, które są generowane w kompilatorze podczas parsowania innych języków. Ale te drzewa parsowania są w pełni dostępne dla twoich programów. Możesz pisać programy, które je manipulują. W Lisp te programy nazywają się makrami. Są to programy, które piszą programy.
Programy, które piszą programy? Kiedy chciałbyś to zrobić? Niezbyt często, jeśli myślisz w Cobol. Cały czas, jeśli myślisz w Lisp. Byłoby tu wygodnie, gdybym mógł podać przykład potężnego makra i powiedzieć: proszę bardzo, jak to jest? Ale gdybym to zrobił, dla kogoś, kto nie zna Lispa, wyglądałoby to po prostu jak bełkot; nie ma tu miejsca, aby wyjaśnić wszystko, co trzeba wiedzieć, aby zrozumieć, co to znaczy. W Ansi Common Lisp starałem się posunąć rzeczy tak szybko, jak tylko mogłem, a nawet wtedy nie dotarłem do makr aż do strony 160.
Ale myślę, że mogę przedstawić rodzaj argumentu, który może być przekonujący. Kod źródłowy edytora Viaweb składał się prawdopodobnie w około 20-25% z makr. Makra są trudniejsze do napisania niż zwykłe funkcje Lispa, i uważa się za złą praktykę ich używanie, gdy nie są konieczne. Więc każde makro w tym kodzie jest tam, ponieważ musiało być. Oznacza to, że co najmniej 20-25% kodu w tym programie wykonuje czynności, których nie można łatwo wykonać w żadnym innym języku. Niezależnie od tego, jak sceptyczny byłby programista Bluba wobec moich twierdzeń o tajemniczych mocach Lispa, to powinno go zaciekawić. Nie pisaliśmy tego kodu dla własnej rozrywki. Byliśmy małym startupem, programującym tak ciężko, jak tylko mogliśmy, aby stworzyć bariery techniczne między nami a naszymi konkurentami.
Podejrzliwa osoba mogłaby zacząć się zastanawiać, czy istnieje jakaś korelacja. Duża część naszego kodu wykonywała czynności, które są bardzo trudne do wykonania w innych językach. Powstałe oprogramowanie robiło rzeczy, których oprogramowanie konkurencji nie mogło zrobić. Może istniało jakieś powiązanie. Zachęcam do podążania tym tropem. Może być więcej w tym starym człowieku kulejącym na swoich kulach, niż się wydaje.
Aikido dla Startupów
Ale nie spodziewam się nikogo przekonać (powyżej 25 lat) do wyjścia i nauki Lispa. Celem tego artykułu nie jest zmiana czyjegoś zdania, ale uspokojenie osób już zainteresowanych używaniem Lispa – ludzi, którzy wiedzą, że Lisp jest potężnym językiem, ale martwią się, ponieważ nie jest szeroko używany. W sytuacji konkurencyjnej jest to zaleta. Moc Lispa jest potęgowana przez fakt, że twoi konkurenci tego nie rozumieją.
Jeśli myślisz o użyciu Lispa w startupie, nie powinieneś martwić się, że nie jest on szeroko rozumiany. Powinieneś mieć nadzieję, że tak pozostanie. I prawdopodobnie tak będzie. Jest w naturze języków programowania, że większość ludzi jest zadowolona z tego, czego aktualnie używa. Sprzęt komputerowy zmienia się znacznie szybciej niż osobiste nawyki, więc praktyka programowania jest zazwyczaj o dziesięć do dwudziestu lat za procesorem. W miejscach takich jak MIT pisano programy w językach wysokiego poziomu na początku lat 60., ale wiele firm nadal pisało kod w języku maszynowym aż do lat 80. Założę się, że wiele osób nadal pisało w języku maszynowym, dopóki procesor, niczym barman chętny do zamknięcia i powrotu do domu, ostatecznie ich nie wyrzucił, przechodząc na zestaw instrukcji risc.
Zwykle technologia zmienia się szybko. Ale języki programowania są inne: języki programowania to nie tylko technologia, ale to, w czym myślą programiści. Są w połowie technologią, a w połowie religią.[6] I tak język mediany, czyli język używany przez przeciętnego programistę, porusza się powoli jak góra lodowa. Zbieranie śmieci, wprowadzone przez Lispa około 1960 roku, jest obecnie powszechnie uważane za dobrą rzecz. Typowanie w czasie wykonania, podobnie, zyskuje na popularności. Domknięcia leksykalne, wprowadzone przez Lispa na początku lat 70., są obecnie, ledwo, na radarze. Makra, wprowadzone przez Lispa w połowie lat 60., są nadal terra incognita.
Oczywiście, język mediany ma ogromną siłę napędową. Nie proponuję, abyś walczył z tą potężną siłą. Proponuję dokładnie odwrotnie: że, podobnie jak praktykujący Aikido, możesz ją wykorzystać przeciwko swoim przeciwnikom.
Jeśli pracujesz w dużej firmie, może to nie być łatwe. Będziesz miał trudności z przekonaniem szefa do pozwolenia ci na budowanie rzeczy w Lisp, kiedy właśnie przeczytał w gazecie, że jakiś inny język ma zamiar, podobnie jak Ada dwadzieścia lat temu, przejąć świat. Ale jeśli pracujesz w startupie, który jeszcze nie ma szefów, możesz, tak jak my, obrócić paradoks Bluba na swoją korzyść: możesz używać technologii, której twoi konkurenci, przyklejeni nieodwołalnie do języka mediany, nigdy nie będą w stanie dorównać.
Jeśli kiedykolwiek znajdziesz się w startupie, oto przydatna wskazówka dotycząca oceny konkurentów. Czytaj ich oferty pracy. Wszystko inne na ich stronie może być zdjęciami stockowymi lub ich prozatorskim odpowiednikiem, ale oferty pracy muszą być konkretne w tym, czego chcą, inaczej zdobędą niewłaściwych kandydatów.
W latach, gdy pracowaliśmy nad Viaweb, czytałem wiele opisów stanowisk. Nowy konkurent wydawał się pojawiać znikąd co miesiąc. Pierwszą rzeczą, którą robiłem, po sprawdzeniu, czy mają działające demo online, było przeglądanie ich ofert pracy. Po kilku latach tego robiłem, mogłem stwierdzić, które firmy należy się obawiać, a które nie. Im bardziej oferty pracy miały charakter IT, tym mniej niebezpieczna była firma. Najbezpieczniejsze były te, które wymagały doświadczenia z Oracle. Nigdy nie trzeba było się nimi martwić. Byłeś też bezpieczny, jeśli mówili, że szukają programistów C++ lub Java. Jeśli szukali programistów Perla lub Pythona, byłoby to trochę przerażające – zaczyna to brzmieć jak firma, w której przynajmniej strona techniczna jest prowadzona przez prawdziwych hakerów. Gdybym kiedykolwiek zobaczył ofertę pracy szukającą hakerów Lispa, byłbym naprawdę zaniepokojony.
Przypisy
[1] Viaweb początkowo składał się z dwóch części: edytora, napisanego w Lisp, którego używali ludzie do tworzenia swoich stron, oraz systemu zamówień, napisanego w C, który obsługiwał zamówienia. Pierwsza wersja była w większości w Lisp, ponieważ system zamówień był niewielki. Później dodaliśmy dwa kolejne moduły: generator obrazów napisany w C i menedżer zaplecza napisany głównie w Perlu.
W styczniu 2003 roku Yahoo wydało nową wersję edytora napisaną w C++ i Perlu. Trudno jednak powiedzieć, czy program nie jest już napisany w Lisp, ponieważ aby przetłumaczyć ten program na C++, dosłownie musieli napisać interpreter Lispa: pliki źródłowe wszystkich szablonów generujących strony nadal, o ile wiem, są kodem Lispa. (Zobacz Dziesiąta zasada Greenspuna.)
[2] Robert Morris mówi, że nie musiałem być tajemniczy, ponieważ nawet gdyby nasi konkurenci wiedzieli, że używamy Lispa, nie zrozumieliby dlaczego: „Gdyby byli tak mądrzy, już programowaliby w Lisp”.
[3] Wszystkie języki są równie potężne w sensie równoważności Turinga, ale to nie jest sens słowa, który jest ważny dla programistów. (Nikt nie chce programować maszyny Turinga.) Rodzaj mocy, który jest ważny dla programistów, może nie być formalnie definiowalny, ale jednym ze sposobów jego wyjaśnienia byłoby stwierdzenie, że odnosi się on do funkcji, które można by uzyskać w mniej potężnym języku tylko poprzez napisanie w nim interpretera dla potężniejszego języka. Jeśli język A ma operator do usuwania spacji z ciągów znaków, a język B nie ma, to prawdopodobnie nie czyni to A potężniejszym, ponieważ prawdopodobnie można napisać podprogram, aby to zrobić w B. Ale jeśli A obsługuje, powiedzmy, rekurencję, a B nie, to nie jest to coś, co można naprawić, pisząc funkcje biblioteczne.
[4] Uwaga dla nerdów: lub być może kratownica, zwężająca się ku górze; liczy się tu nie kształt, ale idea, że istnieje co najmniej częściowy porządek.
[5] Traktowanie makr jako oddzielnej funkcji jest nieco mylące. W praktyce ich użyteczność jest znacznie zwiększona przez inne funkcje Lispa, takie jak domknięcia leksykalne i parametry resztkowe.
[6] W rezultacie porównania języków programowania przybierają albo formę wojen religijnych, albo podręczników akademickich tak zdecydowanie neutralnych, że są właściwie dziełami antropologii. Ludzie, którzy cenią sobie spokój lub chcą uzyskać stałe zatrudnienie, unikają tego tematu. Ale pytanie jest tylko w połowie religijne; jest tam coś, co warto zbadać, zwłaszcza jeśli chce się projektować nowe języki.