Problem z programowaniem

W latach 80. i 90. Bjarne Stroustrup zaprojektował i wdrożył język programowania C++, który spopularyzował programowanie obiektowe i wpłynął na wiele innych języków programowania, w tym Java.

C++ pozostaje archetypowym językiem komputerowym wysokiego poziomu (to znaczy takim, który zachowuje cechy naturalnego, ludzkiego języka) i nadal jest używany przez miliony programistów. Wiele systemów i aplikacji ery PC i Internetu zostało napisanych w C++. Mimo wszystko język pozostaje kontrowersyjny, głównie dlatego, że jest bardzo trudny do nauczenia i używania, a także dlatego, że projekt Stroustrupa pozwala programistom popełniać poważne błędy programistyczne w interesie zachowania ich wolności.

Stroustrup, wieloletni pracownik naukowy AT&T Bell Labs, obecnie jest profesorem informatyki na Wydziale Inżynierii Uniwersytetu Texas A&M niedaleko Houston.

Przegląd technologii : Dlaczego większość oprogramowania jest tak zła?

Bjarne Stroustrup : Niektóre programy są całkiem dobre według wszelkich standardów. Pomyśl o marsjańskich łazikach, Google i projekcie ludzkiego genomu. To wysokiej jakości oprogramowanie! Piętnaście lat temu większość ludzi, a zwłaszcza większość ekspertów, powiedziałaby, że każdy z tych przykładów jest niemożliwy. Nasza cywilizacja technologiczna zależy od oprogramowania, więc gdyby oprogramowanie było tak złe, jak jego najgorsza reputacja, większość z nas już by nie żyła.

Z drugiej strony patrzenie na przeciętne fragmenty kodu może wywołać u mnie płacz. Struktura jest przerażająca, a programiści najwyraźniej nie zastanawiali się nad poprawnością, algorytmami, strukturami danych ani konserwowalnością. Większość ludzi tak naprawdę nie czyta kodu; po prostu widzą, że Internet Explorer się zawiesza.

Myślę, że prawdziwym problemem jest to, że my (to znaczy my, programiści) jesteśmy w ciągłym stanie zagrożenia, chwytając się brzytwy, aby wykonać naszą pracę. Dokonujemy wielu drobnych cudów metodą prób i błędów, nadmiernego użycia brutalnej siły i wielu, wielu testów, ale – tak często – to nie wystarczy.

Twórcy oprogramowania opanowali trudną sztukę budowania w miarę niezawodnych systemów z zawodnych części. Problem polega na tym, że często nie wiemy dokładnie, jak to zrobiliśmy: system po prostu ewoluował w coś minimalnie akceptowalnego. Osobiście wolę wiedzieć, kiedy system będzie działał i dlaczego.

DZIECI : Jak możemy naprawić bałagan, w którym się znajdujemy?

BS : Teoretycznie odpowiedź jest prosta: lepiej edukuj naszych programistów, stosuj bardziej odpowiednie metody projektowania i projektuj pod kątem elastyczności i na dłuższą metę. Nagradzaj poprawne, solidne i bezpieczne systemy. Ukarać niechlujstwo.

W rzeczywistości to niemożliwe. Ludzie nagradzają programistów, którzy dostarczają oprogramowanie, które jest tanie, z błędami i pierwsze. To dlatego, że ludzie chcą teraz nowych, wymyślnych gadżetów. Oni nie chcą niedogodności, nie chcą uczyć się nowych sposobów interakcji ze swoimi komputerami, nie chcą opóźnień w dostawie i nie chcą płacić dodatkowo za jakość (chyba że jest to oczywiste z góry – a często nawet wtedy). A bez rzeczywistych zmian w zachowaniu użytkowników dostawcy oprogramowania raczej się nie zmienią.

Nie możemy zatrzymać świata na dekadę, przeprogramowując wszystko, od naszych ekspresów do kawy po nasze systemy finansowe. Z drugiej strony samo plątanie się jest drogie, niebezpieczne i przygnębiające. Potrzebne są znaczące ulepszenia, które mogą nastąpić tylko stopniowo. Muszą nadejść szerokim frontem; żadna pojedyncza zmiana nie jest wystarczająca.

Jednym z problemów jest to, że akademickie kominy przeszkadzają: zbyt wiele osób promuje jakiś obszar jako panaceum. Lepsze metody projektowania mogą pomóc, lepsze techniki specyfikacji mogą pomóc, lepsze języki programowania mogą pomóc, lepsze technologie testowania mogą pomóc, lepsze systemy operacyjne mogą pomóc, lepsza infrastruktura oprogramowania pośredniego może pomóc, lepsze zrozumienie domen aplikacji może pomóc, lepsze zrozumienie danych struktury i algorytmy mogą pomóc – i tak dalej. Na przykład teoria typów, rozwój oparty na modelach i metody formalne mogą niewątpliwie zapewnić znaczną pomoc w niektórych obszarach, ale są promowane jako ten rozwiązanie z wykluczeniem innych podejść, każde gwarantuje niepowodzenie w projektach na dużą skalę. Ludzie popychają to, co wiedzą i to, co widzieli, działa; jak mogliby zrobić inaczej? Ale niewielu ma dojrzałość techniczną, aby zrównoważyć wymagania i zasoby.

DZIECI : Ideą C++ było to, aby programiści pracowali ciężej w zamian za bardziej wydajny kod. Bell Labs chciał języka, którego kilka naprawdę inteligentnych ludzi używałoby do pisania kodu, który działałby na komputerach takich jak elektroniczne systemy przełączania (ESS), które nie były zbyt szybkie. Obecnie jest wielu programistów, a komputery są bardzo szybkie. Czy to jest sprzeczne z celem C++?

BS : C++ nie został zaprojektowany specjalnie dla dużych maszyn przełączających, ale dla szerokiego zakresu zastosowań. Bell Labs było domem niesamowitej gamy interesujących projektów obejmujących każdą skalę i wykorzystujących zasadniczo każdy rodzaj komputera i systemu operacyjnego. Ale tak, przeciętny programista Bell Labs był znacznie bardziej zdolny niż większość ludzi wyobrażenie przeciętnego programisty, a niezawodność i wydajność (w tej kolejności) były uważane za znacznie ważniejsze niż w większości innych miejsc.

Wydajność nadal jest problemem w wielu interesujących mnie aplikacjach: responsywność interfejsów, czas uruchamiania i zamykania aplikacji. Twórcy oprogramowania zneutralizowali zdumiewającą wydajność nowoczesnego sprzętu komputerowego, dodając kolejne warstwy przepracowanych abstrakcji [oprogramowania]. Wydaje się, że osiągnęliśmy granice szybkości liniowej dla sprzętu, ale w wielu przypadkach moglibyśmy odzyskać kilka rzędów wielkości z oprogramowania.

To powiedziawszy, C++ rzeczywiście stał się zbyt przyjazny dla ekspertów w czasie, gdy spadł stopień efektywnej formalnej edukacji przeciętnego programisty. Jednak rozwiązaniem nie jest ogłupianie języków programowania, ale używanie różnych języków programowania i kształcenie większej liczby ekspertów. Muszą istnieć języki, z których mogą korzystać ci eksperci – a C++ jest jednym z tych języków.

DZIECI : Czy patrząc wstecz, przy projektowaniu C++, twoja decyzja o kompromisie między wydajnością programisty, bezpieczeństwem i niezawodnością oprogramowania a wydajnością w czasie wykonywania nie była fundamentalnym błędem?

BS : Cóż, nie sądzę, że dokonałem takiego kompromisu. chcę elegancko oraz wydajny kod. Czasami to rozumiem. Te dychotomie (między wydajnością a poprawnością, efektywnością a czasem programisty, efektywnością a wysokim poziomem itd.) są fałszywe.

To, co zrobiłem, to zaprojektowanie C++ jako przede wszystkim języka programowania systemów: chciałem móc pisać sterowniki urządzeń, systemy wbudowane i inny kod, który wymagał bezpośredniego użycia sprzętu. Następnie chciałem, aby C++ był dobrym językiem do projektowania narzędzi. Wymagało to elastyczności i wydajności, ale także umiejętności wyrażania eleganckich interfejsów. Moim zdaniem, aby robić rzeczy na wyższym poziomie, aby zbudować kompletne aplikacje, najpierw trzeba kupić, zbudować lub wypożyczyć biblioteki zapewniające odpowiednie abstrakcje. Często, gdy ludzie mają problemy z C++, prawdziwym problemem jest to, że nie mają odpowiednich bibliotek lub nie mogą znaleźć dostępnych bibliotek.

Inne języki próbowały bardziej bezpośrednio obsługiwać aplikacje wysokiego poziomu.

To działa, ale często to wsparcie odbywa się kosztem specjalizacji. Osobiście nie zaprojektowałbym narzędzia, które mogłoby robić tylko to, co chciałem – dążę do ogólności.

DZIECI : Jak wytłumaczyć fakt, że C++ jest zarówno szeroko krytykowany, jak i oburzany przez wielu programistów, ale jednocześnie bardzo szeroko stosowany? Dlaczego jest tak skuteczny?

BS : Gładka odpowiedź brzmi: są tylko dwa rodzaje języków: ten, na który wszyscy narzekają, i ten, którego nikt nie używa.

Istnieje więcej użytecznych systemów opracowanych w językach uważanych za okropne niż w językach chwalonych za piękne – o wiele więcej. Celem języka programowania jest pomoc w budowaniu dobrych systemów, w których dobro można definiować na wiele sposobów. Moja krótka definicja jest poprawna, łatwa do utrzymania i odpowiednio szybka. Estetyka ma znaczenie, ale przede wszystkim język musi być użyteczny; musi umożliwiać programistom z prawdziwego świata wyrażanie rzeczywistych pomysłów zwięźle i po przystępnej cenie.

Głównym powodem sukcesu C++ jest po prostu to, że spełnia swoje ograniczone cele projektowe: może bezpośrednio i skutecznie wyrażać ogromną gamę pomysłów. C++ nie został zaprojektowany do robienia tylko jednej rzeczy naprawdę dobrze lub do zapobiegania robieniu rzeczy uważanych za złe. Zamiast tego skupiłem się na ogólności i wydajności.

Jestem pewien, że na każdego programistę, który nie lubi C++, znajdzie się taki, który go lubi. Jednak mój przyjaciel poszedł na konferencję, na której główny mówca poprosił publiczność o wskazanie przez podniesienie ręki, jeden, ile osób nie lubi C++, a dwa, ile osób napisało program C++. W pierwszej grupie było dwa razy więcej osób niż w drugiej. Wyrażanie niechęci do czegoś, czego nie znasz, jest zwykle znane jako uprzedzenie. Ponadto narzekający są zawsze głośniejsi i bardziej pewni niż zwolennicy – ​​rozsądni ludzie przyznają się do wad. Myślę, że wiem więcej o problemach z C++ niż ktokolwiek inny, ale wiem też, jak ich uniknąć i jak wykorzystać mocne strony C++.

A potem, oczywiście, nie oczekujesz, że zwolennicy języków, które przegrały w konkurencji z C++, będą uprzejmi. Tworzenie oprogramowania nie ma takiego stopnia profesjonalizmu – chociaż mam nadzieję, że w końcu tak się stanie. Pod tym względem nauka jest inna: kiedy wygrywa nowe narzędzie, technika lub teoria, ludzie postrzegają to jako postęp. W oprogramowaniu wkład konkurentów i poprzedników nie jest powszechnie uznawany, doceniany, a nawet rozumiany.

DZIECI : W Projekt i ewolucja C++ , twierdzisz, że Kierkegaard miał wpływ na twoją koncepcję języka. Czy to żart?

BS : Może trochę pretensjonalny, ale to nie żart. Wiele myśli o tworzeniu oprogramowania skupia się na grupie, zespole, firmie. Często dochodzi do tego, że jednostka jest całkowicie zanurzona w kulturze korporacyjnej bez ujścia dla unikalnych talentów i umiejętności. Praktyki korporacyjne mogą być bezpośrednio wrogie osobom o wyjątkowych umiejętnościach i inicjatywie w kwestiach technicznych. Takie zarządzanie ludźmi technicznymi uważam za okrutne i marnotrawne. Kierkegaard był zagorzałym orędownikiem walki indywidualnej z tłumem i poważnie dyskutował na temat znaczenia estetyki i etycznego zachowania. Nie mogłem wskazać konkretnej cechy języka i powiedzieć: Widzisz, jest wpływ dziewiętnastowiecznego filozofa, ale jest on jednym z korzeni mojej niechęci do eliminowania cech na poziomie eksperckim, usuwania nadużyć i ograniczania funkcji do obsługują tylko te zastosowania, o których wiem, że są przydatne. Nie przepadam jednak za filozofią religijną Kierkegaarda.

DZIECI : Czego najbardziej żałujesz?

BS : Bez żalu! Cóż, oczywiście marzę o tym, co mógłbym zrobić inaczej i lepiej, ale poważnie, kim jestem, żeby odgadnąć, powiedzmy, rocznik 1984 Bjarne? Być może był mniej doświadczony ode mnie, ale był nie mniej bystry, prawdopodobnie mądrzejszy i lepiej niż ja rozumiał słowo Rok 1984. C++ był używany do budowania wielu systemów, które poprawiają nasze życie i miał znaczący pozytywny wpływ na późniejsze języki i systemy. To jest coś, z czego można być dumnym.

Kliknij tutaj do przeczytania naszego drugiego wywiadu ze Stroustrupem.

ukryć