Dziwne losy PHP, JS i BASIC

Czasem wychodzi tak, że dzieje się inaczej, niż zakładaliśmy. Podobnie może być z rozwojem software’u. W początkach swojej kariery miałem ciekawy przykład takiej złośliwości losu.

Dostałem zadanie zrobienia PoC apki na iOS opartej na PhoneGapie. Jeden haczyk - musiała być gotowa na targi za dwa tygodnie. Wygląd i zachowanie były mocno niestandardowe, więc od początku jasne było, że 95% czasu będę musiał spędzić nad szlifowaniem tego, co użytkownik zobaczy. Potrzebowałem jeszcze danych z istniejącego już backendu. Problem był taki, że do tej pory zwracał on dane w zupełnie innym formacie. Klienci autentykowali się w bardzo specyficzny sposób i dane nie odpowiadały temu, co bym chciał dostać. Poszedłem więc do chłopaków, którzy wtedy zajmowali się backendem, z prośbą o kilka endpointów. Usłyszałem:

Stary, mamy wdrożenie u klienta. Kompletnie nie mamy czasu na projektowanie nowego API. Weź, napisz sobie na szybko te endpointy. Za dwa tygodnie to zaprojektujemy i przepiszemy.

„Za dwa tygodnie” wydarzyło się „za rok”. W tym czasie aplikacja, którą robiłem, wylądowała na pilotażowym wdrożeniu u klienta i korzystała z backendu bazującego na tym, co pierwotnie skleciłem w pół godzinki.

Podobne sytuacje działy się w znacznie poważniejszych projektach. Pierwotne założenie - często bardzo dobre - po prostu nie wytrzymywało zderzenia z rzeczywistością, sytuacją na rynku czy potrzebami użytkowników. Poniżej przeczytacie o trzech językach programowania, które rozwinęły się w innym kierunku, niż początkowo zakładali ich twórcy.

Historia PHP

To język, który od zawsze zbiera mnóstwo hejtu za to, jaki jest beznadziejny. Dziwny miks programowania obiektowego i funkcji dostępnych globalnie. Wszędzie te dolary i w ogóle - tragedia. Jak do tego dołoży się książki z zeszłego dziesięciolecia, gdzie były przykłady tego typu:

$result = mysql_query("SELECT * FROM {$table}");
if (!$result) {
    die("Query to show fields from table failed");
}

$fields_num = mysql_num_fields($result);

echo "<h1>Table: </h1>";
echo "<table border='1'><tr>";
// printing table headers
for($i=0; $i<$fields_num; $i++)
{
    $field = mysql_fetch_field($result);
    echo "<td>{$field->name}</td>";
}
echo "</tr>\n";
while($row = mysql_fetch_row($result))
{
    echo "<tr>";
    foreach($row as $cell)
        echo "<td>$cell</td>";
    echo "</tr>\n";
}
mysql_free_result($result);

...to wszystko staje się jasne. Ale czemu ktoś w ogóle wpadł na powołanie do życia takiego czegoś?

Rasmus Lerdorf - twórca PHP - na konferencji .concat() 2018 powiedział nieco o tym, czemu zdecydował się na zrobienie nowego języka programowania. Okazuje się, że w 1993 roku aplikacje webowe pisało się np. w C. Musiały one generować HTML - a wielu programistów backendowych nie lubi grzebania w HTML-u. Już wtedy przekazywało się kod frontendowcom, którzy niestety mieli blade pojęcie o C. Często więc psuli przekazywany im program.

Innym rozwiązaniem z tego okresu był Perl i popularny moduł CGI.pm. Jednak to też nie było idealne dla Rasmusa, bo frontendowiec nadal musiał radzić sobie z czymś, co kompletnie nie wygląda jak HTML i co łatwo popsuć. Chciał więc mieć coś, co może dać ludziom, którzy zajmowali się HTML-em. Coś, co wygląda jak HTML i ma tylko malutkie wstawki do wyciągania interesujących danych z backendu. Chciał mieć system do robienia szablonów, który będzie dobrze się integrować z całą resztą aplikacji w C, w której jest cała logika. I dokładnie taka idea przyświecała PHP. Jak to ładnie powiedział, chciał, by PHP było API C dla zastosowań webowych.

Domyślacie się więc, że Lerdorf nie chciał robić z PHP pełnoprawnego języka programowania, bo tym był dla niego C. Programiści z tego okresu mieli jednak nieco inny pomysł na przyszłość PHP. W początkowym okresie rozwój API był całkowicie organiczny. Pojawiało się coraz więcej funkcji i możliwości, co otworzyło drogę do wrzucania coraz większej ilości logiki w widoku. Nie dlatego, że to świetny pomysł. Raczej dlatego, że - po pierwsze - nie było to zakazane, a - po drugie - na początku było bardzo wygodne.

Pojawiła się pokusa pisania pełnych aplikacji w PHP, jednak pierwsze wersje języka zupełnie się do tego nie nadawały. Tu na scenę wkraczają Zeev Suraski i Andi Gutmans, którzy chcieli wykorzystać PHP do napisania aplikacji e-commerce. Skontaktowali się więc z Rasmusem, by przedyskutować znaczne rozszerzenie funkcjonalności języka. Tak powstało PHP 3.0, a wraz z nim zapisała się historia, którą lepiej pamiętamy. PHP stało się pełnoprawnym językiem programowania z elementami obiektowymi i ułatwieniami służącymi budowaniu aplikacji webowych. Przy okazji Zeev i Andi założyli firmę Zend. Udało im się zrobić karierę na tym projekcie.

Prawie 20 lat zajęło przepisanie PHP w taki sposób, by nie był zakałą wśród popularnych języków programowania. W międzyczasie zrobiliśmy na nim olbrzymią część rozwoju weba, a Facebook poświęcił lata, by dostosować ten język do potrzebnej mu skali.  Nieźle jak na coś, co miało służyć do robienia szablonów.

Historia BASIC-a

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Znacie ten cytat? To mocne zdanie, napisane przez Edsgera Dijkstrę w jego dość znanym rancie na temat języków programowania.

Mimo to, BASIC zrobił sporą karierę, szczególnie w latach 70. i 80.

Założeniem było stworzenie prostego języka programowania, który umożliwiłby kodowanie ludziom z dziedzin innych, niż informatyka. Widać to w pierwotnym manualu BASIC-a, który zaczyna się od wytłumaczenia, czym w zasadzie jest program. Kolejny rozdział to nie suche definicje, a przykłady wraz z objaśnieniami. Język został zaprojektowany do użycia z Dartmouth Time Sharing System - pierwszym na świecie systemem do współdzielenia czasu między wielu użytkowników, który udało się zaimplementować na większą skalę. W Dartmouth College - gdzie powstał zarówno DTSS, jak i BASIC - wyniki były świetne. Przez cztery lata od wprowadzenia systemu aż 80% studentów uczelni miało za sobą doświadczenie z programowaniem, co nawet dziś robi duże wrażenie.

Koncept prostego języka programowania przyjął się znakomicie. Powstały kolejne dialekty i implementacje BASIC-a, w tym wspierane przez producentów minikomputerów, które pojawiały się w drugiej połowie lat 60. Prawdziwa eksplozja popularności nastąpiła w połowie lat 70., kiedy pojawiły się mikrokomputery (czyli na nasze: komputery domowe). W zasadzie każdy system miał wbudowany interpreter BASIC-a. Był to język entuzjastów i hobbystów komputerów.

BASIC ewoluował i z biegiem czasu umożliwiał coraz więcej - np. tworzenie gier czy programów użytkowych. W latach 80. w czasopismach publikowano całe programy w BASIC-u, które można było przepisać u siebie na komputerze. Na tym etapie język, w którym pierwotnie można było rozwiązywać proste zadania algebraiczne, umożliwiał rysowanie czy sterowanie dźwiękiem. Trzeba pamiętać, że ciągle mówimy tu o zastosowaniach amatorskich i półprofesjonalnych. Większość krytyki, która spadła na BASIC była związana z próbami uczenia informatyki na tym języku, bądź wykorzystaniu go w większych projektach.

Na pamięć o BASIC-u wpływa na pewno to, co zrobił z nim Microsoft, gdy w oparciu o tę grupę języków stworzył język nowy - Visual Basic. Założeniem twórców nadal była łatwość nauki, jednak dołożono elementy obiektowe czy programowania zdarzeniowego. Kolejną intencją była możliwość tworzenia aplikacji z poziomu GUI. To prawda, że VB przyjął się nieźle wśród małych przedsiębiorców, którzy w miarę tanio mogli stworzyć program spełniający ich skromne potrzeby. Skoro tu był mały sukces, to może spróbować na innych polach? Chyba tak właśnie pomyślał ktoś z MS, bo w 2001 roku wypuścili Visual Basic .NET, czyli nowy dialekt Visual Basic na platformie .NET. Tu już chodziło o zastosowania stricte profesjonalne. Tych różnych wersji Visual Basica Microsoft naprodukował kilka. Każda potrafi coś nieco innego, każda ma inne ograniczenia i mocne strony, różnią się między sobą również użytymi paradygmatami.

I to wszystko wyewoluowało z języka, który miał służyć do uczenia programowania ludzi, którzy nie mieli styczności z informatyką. Na czymś, co w założeniu miało być proste, powstał skomplikowany ekosystem, a to nie spodobało się programistom. W ankiecie StackOverflow praktycznie od początku różne wersje Visual Basic okupują szczyt listy najbardziej nielubianych języków.

Historia JavaScriptu

Na pewno spodziewaliście się JS na tej liście. O jego historii na Bulldogu wspominaliśmy już parę razy, więc tym razem ograniczę się do oryginalnych planów dla tego języka i jak to się stało, że jesteśmy tu, gdzie jesteśmy - w dużym uproszczeniu.

Brendan Eich dołączył do Netscape, by - w ich nowej przeglądarce Mosaic - osadzić język programowania, w zamierzeniu Scheme lub coś podobnego. Netscape chciał, by ich przeglądarka była bardziej dynamiczna. Eich tak wspomina cel, jaki mu przyświecał:

[...] HTML needed a "scripting language", a programming language that was easy to use by amateurs and novices, where the code could be written directly in source form as part of the Web page markup. We aimed to provide a "glue language" for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the "component language" used by higher-priced programmers, where the glue programmers - the Web page designers - would assemble components and automate their interactions using JS.

Kierownictwo firmy chciało jednak, żeby składnia była podobna do Javy - najmodniejszej nowości w owym czasie. Zlecili Eichowi napisanie prototypu, który powstał w - legendarne już - 10 dni. To trochę mało jak na język programowania, z drugiej strony, hej… przecież z tego nikt nie będzie strzelać. W końcu JS ma tylko zmieniać kolorki elementów na stronie, prawda?

Pół roku później Netscape próbował przenieść JS na stronę serwerową, gdzie miał wspomagać Netscape Enterprise Server. Deweloperzy, którzy mieli styczność z tym produktem wspominają, że korzystanie z niego było katorgą. JS i jego ekosystem po prostu nie były na tyle rozwinięte, by wspomagać programistę w tworzeniu bardziej skomplikowanych aplikacji. Jest to rzadko wspominany rozdział historii języka.

Późniejsza historia pokazuje, że wszystko poszło nieco inaczej, niż początkowo zakładano. Microsoft zaprojektował XMLHttpRequest, który posłużył jako podstawa AJAX, co de facto otworzyło drogę do robienia aplikacji frontendowych. Większa ilość kodu zaczęła tworzyć dużą presję na silnikach JS i potrzeba było czegoś szybszego. Pierwszym przełomem w tej dziedzinie było powstanie w Google silnika V8. Jak pewnie wiecie, Ryan Dahl opakował go w coś, co dziś znamy jako Node.js. Równolegle, jak grzyby po deszczu, zaczęły pojawiać się frameworki do pisania aplikacji frontedowych. Single Page Applications rozpoczęły podbój rynku. Popyt na JS wystrzelił w niebo.

W międzyczasie ECMA (czyli organizacja standaryzująca JS) robi, co może, by dostosować JS do wykonywanych obecnie zadań. Szczególnie ostatnie kilka lat to duża praca nad rozwojem języka, a także próby alternatywnego podejścia do kwestii JS - czyli np. TypeScript.

Wyszło jak zwykle 

Pierwotne założenia często nie wytrzymują zetknięcia z rzeczywistością. Często nie biorą pod uwagę, że ludzie są leniwi i jeżeli jest jakaś możliwość, to na pewno z niej skorzystają mimo, że nie powinni - co pokazuje historia PHP. W przypadku BASIC-a bardziej chodziło o wykorzystanie popularności do własnych celów Microsoftu, a te były inne, niż pierwotne założenia. To zwróciło się przeciwko nim. Osoby odpowiedzialne za początki JavaScript nie przewidziały, jak potężne może to być narzędzie. Tak samo jak nie przewidziały, jak wielki będzie popyt na nowe możliwości, które JS stworzył.

I to są bardzo ludzkie scenariusze w rozwoju informatyki - nikt nie ma szklanej kuli. Następnym razem, gdy zobaczysz kod sprzed kilku lat, który nie wygląda tak, jakbyś chciał, to nie pytaj gniewnie: „jak ktoś mógł tego nie przewidzieć???!!!!11jeden”. Możesz podejść do sprawy z większą wyrozumiałością - a energia przyda się do zmieniania systemu tak, by sprostał nowym wymaganiom.