Wszystko, co możesz zrobić, mogę zrobić Meta

9 kwietnia na odległym lądowisku na równinach Kazachstanu kontroler naziemny zakończy odliczanie; wystrzeli rakieta Sojuz; i Charles Simonyi – były główny architekt firmy Microsoft, geniusz opiekuńczy odpowiedzialny za jej najsłynniejsze aplikacje, wynalazca metody pisania kodu, której programiści firmy używali od 25 lat, a teraz orędownik ambitnego projektu przeprogramowania oprogramowania – rozpoczną jego wznoszenie się w kosmos.

Charles Simonyi, prezes i dyrektor generalny firmy Intentional Software.

Przytulony w rosyjskim skafandrze kosmicznym, czując, jak cztery G wciskają go w dopasowaną do kształtu wyściółkę siedzenia, 58-letni miliarder zostanie piątym kosmicznym turystą, który odwiedzi Międzynarodową Stację Kosmiczną. Podróż, która będzie kosztować Simonyiego około 20 milionów dolarów, spełni jego marzenie o zostaniu nerdem w kosmosie (by pożyczyć jedną nazwę, którą wybrał dla strony internetowej dokumentującej jego pozaziemską przygodę: www.nerdinspace.com ). Da mu również możliwość spojrzenia na naszą planetę z góry i spoza niej.

To zawsze była ulubiona pozycja Simonyiego. W swojej karierze trwającej cztery dekady za każdym razem, gdy mierzy się z jakimś nierozwiązywalnym problemem w oprogramowaniu lub życiu, próbuje go rozwiązać, wychodząc poza lub ponad niego. Ma nawet nazwę dla swojego ulubionego gambitu: nazywa go meta. W młodości, na Węgrzech w latach 60., nauczył się podstaw komputerów na przestarzałym sowieckim komputerze mainframe napędzanym lampami próżniowymi, a następnie zaprojektował własną ucieczkę na Zachód. W latach siedemdziesiątych w legendarnym Centrum Badawczym Palo Alto (PARC) firmy Xerox, jako członek zespołu, który wynalazł komputery osobiste, Simonyi napisał pierwszą nowoczesną aplikację: procesor tekstu, który wyeliminował złożone kody używane następnie do oznaczania tekstu i wyświetlania dokumentu jako wyglądałoby to na papierze. Czy to w jego rozprawie doktorskiej na Uniwersytecie Stanforda na temat podejścia do metaprogramowania w celu zwiększenia produktywności programistów, jego karierze w Microsoft organizującej legiony programistów i uczeniu ich, jak konstruować ich kod, czy też planowanej na wiosnę wyprawie na orbitę ziemską, wykraczającą poza ustalone sposoby robienia rzeczy zawsze była metodą Simonyi. Teraz knuje coś, co, jak ma nadzieję, będzie jego najbardziej przerażającym meta-ruchem ze wszystkich. Simonyi wierzy, że może rozwiązać wiele upartych problemów, które zawsze nękały komputery, oferując każdemu, kto z nich korzysta, oraz programistom, którzy je programują, wyższy widok oprogramowania.

Bill Gates nazywa Simonyiego jednym z najlepszych programistów wszechczasów. Rzeczywiście, Simonyi jest prawdopodobnie bardzo odnoszący sukcesy programista na świecie, mierzony w kategoriach nagrody finansowej i liczby osób, które korzystają z jego dzieł. (Inni słynni programiści-miliarderzy, tacy jak Larry Ellison i sam Bill Gates, zarobili pieniądze na zakładaniu i zarządzaniu przedsięwzięciami technologicznymi). jacht. Zamiast tego, mówi, programuje prawdopodobnie ciężej niż kiedykolwiek wcześniej. Ma obsesję na punkcie projektu, który realizuje od półtorej dekady i który cztery lata temu wyprowadził go z domu Microsoftu. Jest dumny ze swojego zawodu. Ale prześladuje go również myśl o tym, z czym muszą zmagać się programiści za każdym razem, gdy siadają do programowania. Pyta: Dlaczego tak trudno jest stworzyć dobre oprogramowanie?

Multimedia

• Dodatkowe zdjęcia Simonyi

Kodeks napoleoński

Nasza cywilizacja działa na oprogramowaniu, mówi Bjarne Stroustrup, wynalazca języka programowania C++ (zobacz Problem z programowaniem ) . Ale samo oprogramowanie nie działa zbyt dobrze. Wszędzie, gdzie nie spojrzysz, oprogramowanie przekracza budżet, jest opóźnione, niepewne, zawodne i trudne w użyciu. Za każdym razem, gdy organizacja próbuje wprowadzić nowy system lub zaktualizować stary, podejmuje kolosalne ryzyko; dziś wielkie projekty informatyczne to technologiczne dziury, które unieruchamiają instytucje. Badania regularnie wskazują, że dwie trzecie takich projektów napotyka na poważne opóźnienia, znaczne przekroczenia kosztów lub jedno i drugie. Rząd Stanów Zjednoczonych uznał za prawie niemożliwe wprowadzenie lub aktualizację systemów oprogramowania na dużą skalę: trwające dekadę wysiłki w Federalnej Administracji Lotnictwa i FBI pogrążyły się w chaosie. Firmy nie radziły sobie lepiej. Aby podać jeden przykład, dyrektorzy McDonald's marzyli o internetowym systemie zarządzania, który nazwali Innovate, który śledziłby w czasie rzeczywistym przepływ hamburgerów, frytek i nuggetsów z kurczaka w każdej z ich restauracji na całym świecie. Zanim zrezygnowali i zrezygnowali z projektu, musieli odpisać 170 milionów dolarów z szacowanego całkowitego kosztu 1 miliarda dolarów.

Takie niepowodzenia się sumują. Każdego roku, według badania przeprowadzonego w 2002 roku przez Narodowy Instytut Standardów i Technologii, awarie oprogramowania kosztują 59,5 miliarda dolarów. Ale cenę złego oprogramowania można również zmierzyć w ludzkiej nędzy, a nawet w liczbie utraconych istnień ludzkich. Podczas wojny w Zatoce Perskiej w 1991 roku bateria rakiet Patriot nie wystrzeliła w kierunku nadlatującego Scuda z powodu wadliwego oprogramowania; bezpośrednie trafienie w koszary zabiło 28 żołnierzy amerykańskich.

Ostatnie pół wieku informatyki odnotowało wspaniały postęp. Programiści zrezygnowali z kart dziurkowanych i dalekopisów. Dali nam komputer na każdym pulpicie, narzędzia do pracy, zabawki do zabawy oraz sieć, która łączy domy i firmy, tworząc globalną pulę informacji i rozrywki. Ten postęp jest napędzany przez wykładniczą krzywą prawa Moore'a, przewidywania założyciela Intela Gordona Moore'a, że ​​moc mikrochipów podwoi się (lub ich koszt zmniejszy się o połowę) co rok do dwóch lat. Ale nawet jeśli prawo Moore'a sprawiło, że co roku nowe komputery były szybsze i tańsze, elastyczność i użyteczność naszych systemów komputerowych była ograniczona przez wolniejszą, nierówną ewolucję oprogramowania. Jedno sformułowanie tego problemu znane jest jako prawo Wirtha, po znalezieniu eksperta od programowania Niklausa Wirtha: Oprogramowanie staje się wolniejsze szybciej niż sprzęt.

Simonyi dzieli wiele wspólnego niezadowolenia z oprogramowania. Oprogramowanie, jakie znamy, jest wąskim gardłem cyfrowego rogu obfitości, mówi. Wymaga ogromnych zasobów talentu i czasu. To rozczarowujące i trudne do zmiany. Blokuje innowacje w wielu organizacjach.

Ambicją Simonyi jest zlikwidowanie wąskiego gardła w oprogramowaniu – co jest charakterystyczne dla przejścia na meta. Opracował podejście, które nazywa programowaniem intencjonalnym (lub ostatnio oprogramowaniem intencjonalnym), które, jak ma nadzieję, obali programowanie. Jeśli Simonyi postawi na swoim, programiści przestaną próbować zarządzać potrzebami swoich klientów. Zamiast tego, dla każdego problemu, który mają rozwiązać – czy to śledzenia zapasów, czy wskazówek dotyczących pocisków – stworzą ogólne narzędzia, które sami użytkownicy komputerów mogą modyfikować, aby kierować przyszłą ewolucją oprogramowania.

Pewnego szarego popołudnia w październiku zeszłego roku usiadłem z Simonyi w Bellevue w stanie Waszyngton przed dwoma sąsiadującymi ze sobą ekranami w jego biurze w Intentional Software, firmie, którą założył po odejściu z Microsoftu w 2002 roku, aby rozwijać i skomercjalizować swój wielki pomysł. Simonyi ścigał się ze mną przez prezentację, którą przygotowywał na nadchodzącą konferencję; wykorzystał slajdy programu Microsoft Office PowerPoint, aby nakreślić swoją wizję proponowanego wielkiego kroku naprzód w programowaniu. Był w trakcie przesuwania jednego slajdu, kiedy aplikacja przestała odpowiadać.

W rogu ekranu po lewej stronie pojawił się spinacz do papieru z wyłupiastymi oczami: szeroko znienawidzony Asystent Biurowy, którego Microsoft wprowadził w 1997 roku. Simonyi próbował zignorować wygłupiałe wiercenie się doradcy z kreskówek, ale został unieruchomiony. Nic nie działa, westchnął. To dlatego, że Clippy pomaga mi.

Byłem zdziwiony. Masz na myśli, że nie wyłączyłeś Clippy? Dawno temu przeszukiwałem menu Office i sprawdzałem, które pole jest wymagane, aby raz na zawsze dławić irytującego antropomorfa.

Nie wiem jak, przyznał Simonyi z lekkim śmiechem, który zdawał się mówić: Tak, wiem, czy to nie ironia?

To było. Simonyi przez lata kierował zespołami aplikacji w firmie Microsoft, twórcach programów Word i Excel, z których produktów codziennie korzystają dziesiątki milionów ludzi. Jest powszechnie uważany za ojca Microsoft Word. (Oczywiście używam Worda do pisania tych zdań.) Czy Charles Simonyi mógł spotkać się w Clippy?

Simonyi wpatrywał się w swojego przeciwnika, jakby brał udział w walce telepatycznej. Potem zwrócił się do mnie z błyszczącymi niebieskimi oczami. Potrzebuję pomocnika: Super-Clippy, który pokaże mi, gdzie go wyłączyć! Simonyi tęsknił za meta-Clippym.

W 2004 r. Simonyi zaproponował własne prawo: wszystko, co można zrobić, można zrobić „meta'. W młodości – kiedy nobilitował projekt Simonyi's Infinitely Glorious Network – prawdopodobnie byłby bardziej arogancki: wszystko, co możesz zrobić, mogę zrobić meta! Ale jak wiele cudów, którym dobrze się powodziło i dobrze się postarzały, Simonyi nauczył się ograniczać swoją zarozumiałość pokorą i wdziękiem. Dziesięć lat temu opisał siebie jako kudłatego faceta z obcym akcentem. Lubi czarne golfy i dwurzędowe marynarki. Ze swoją wyprostowaną postawą i kwadratową twarzą, z burzą ciemnych włosów zaczesanych do przodu na czoło, często mówi się, że przypomina Napoleona o większych kościach.

Oprogramowanie celowe to wielki schemat w dziedzinie, w której wielkie schematy rzadko działały. Każda poprzednia innowacja, wprowadzona jako kompletne rozwiązanie problemów oprogramowania, zakończyła się dostarczaniem jedynie skromnych, stopniowych ulepszeń. Ale Simonyi jest pełen pewności siebie imigranta, który sam się stworzył, który zawsze trzymał się swoich własnych butów. Na zdjęciu wiszącym nad jego biurkiem stoi w Białym Domu pod portretem Ronalda Reagana. Jego szeroki uśmiech odzwierciedla uśmiech prezydenta. Podpis głosi Dwóch optymistów.

Biura nowej firmy Simonyiego zajmują apartament w eleganckim szklanym wieżowcu, a jeśli pochylisz się przez okno i spojrzysz w dół, zobaczysz dach przysadzistego, nieokreślonego białego budynku, w którym w 1981 roku mieściło się jego pierwsze biuro w firmie Microsoft. ( Teraz jest to bank.) Od tego czasu Microsoft rozrósł się nie do poznania. Branża oprogramowania zmieniła świat. Dlaczego więc Simonyi miałby przepisać wszystkie zasady? Problem jest tak duży, że wydaje się częścią ustalonego porządku rzeczy. Proponowane przez Simonyiego rozwiązanie może zająć dekady, a jego krytycy są bardzo sceptyczni. Nikt nie prosi go o porzucenie znanych procedur programowania i wyruszenie w nowy świat. Ale takie migracje opłaciły mu się w przeszłości.

Język maszyny

Simonyi urodził się w Budapeszcie w 1948 roku. Syn profesora fizyki, w wieku 15 lat zakochał się w swoim pierwszym komputerze – gigantycznym rosyjskim Uralu II w węgierskim Głównym Urzędzie Statystycznym. W latach sześćdziesiątych Ural, który otrzymał instrukcje za pośrednictwem kluczy kasowych i miał pomieszczenie pełne lamp próżniowych do wykonywania obliczeń, był już reliktem w każdym innym miejscu na świecie. Ale węgierscy przywódcy komunistyczni próbowali wykorzystać sowiecką odrzutę do optymalizacji rozkładów jazdy pociągów i ciężarówek. Ural nie sprostał zadaniu: nie było możliwości wprowadzania danych o przesyłkach w czasie rzeczywistym. To było zupełnie beznadziejne, wspomina Simonyi. Mogło to być zrobione bardzo łatwo dzięki podaży i popytowi. Niestety było to niepoprawne politycznie.

Ale Simonyiego to nie obchodziło. Podobał mi się ten komputer, mówi, chociaż był bezużyteczny. Jako dziecko zbudował samochód Erector Set z czterobiegową skrzynią biegów – nie tyle dlatego, że chciał się nim pobawić, ile po prostu zrozumieć, jak to działa. Były uczeń ojca znalazł Simonyiego jako nocną pielęgniarkę Uralu. Ponieważ maszyna wydmuchiwała rurkę za każdym razem, gdy była wyłączana i włączana, Urząd Statystyczny wolał pozwolić jej działać przez całą noc. Tak więc, od zmierzchu do świtu, mainframe należał w całości do Simonyiego; miał komputer osobisty, zanim takie rzeczy istniały. Nauczył się go programować, pisząc sprytne, ale bezużyteczne procedury generowania magicznych kwadratów — tablic numerycznych, w których sumy rzędów, kolumn i przekątnych pasują do siebie.

Programiści na całym świecie wynaleźli już Babel języków programowania – Fortran, Cobol, Lisp (baśniowy język: patrz Starożytny tekst, s. 20) i tak dalej – aby ułatwić sobie pracę, która wtedy i teraz polegała na żmudnym pisaniu opracować zestawy instrukcji dla komputerów do wykonania. W tych językach instrukcje miały formę wierszy tekstu wprowadzanych na klawiaturach i często przechowywanych na kartach perforowanych. Ten kod źródłowy został następnie skompilowany lub przetłumaczony na kod maszynowy – jeden s i 0 s, które mógłby zrozumieć komputer cyfrowy. Metoda ta pozostaje w dużej mierze niezmieniona do dziś, nawet jeśli większość programistów używa obecnie narzędzi programistycznych działających na zwykłych komputerach PC. Ale na Uralu Simonyi nauczył się programować na bardziej prymitywnym poziomie, mozolnie wbijając opkody języka maszynowego, określając, instrukcja po instrukcji, sekwencje pobierania pamięci, dodawania, przechowywania pamięci i skoków, które musiał wykonać procesor komputera wykonać nawet najbardziej banalną operację. Tak było (jak Simonyi powiedział autorowi Steve'owi Lohrowi w książce z 2001 roku Iść do ) Programowanie epoki kamienia. Simonyi wciąż pamięta kody. Dwadzieścia dwa to JUMP, mówi dzisiaj. Jest wypalony w moim ROM-ie.

Węgry lat sześćdziesiątych, wciąż wzdragające się przed stłumieniem buntu z 1956 roku przez Sowietów, nie były miejscem dla ambitnego młodego człowieka z zamiłowaniem do rozwiązywania problemów. W wieku 17 lat Simonyi odbył staż w duńskiej firmie komputerowej, pokazując niektórym jej programistom próbki swoich ręcznie zakodowanych programów Ural. Władze węgierskie oczekiwały powrotu Simonyi; zdobył już upragnione miejsce na uniwersytecie. Zamiast tego, za namową ojca, uciekł do Stanów Zjednoczonych.

List polecający od duńskiego eksperta ds. programowania, Petera Naura, pomógł mu w zdobyciu wpisu na Uniwersytet Kalifornijski w Berkeley. Zapłacił rachunki, pracując w centrum komputerowym w Berkeley, gdzie zwrócił uwagę członka wydziału o nazwisku Butler Lampson. Lampson był jednym z liderów Project Genie Agencji Zaawansowanych Projektów Badawczych Amerykańskiej Agencji Obrony – eksperymentu w systemach komputerowych z podziałem czasu, w których wielu użytkowników siedzących przy terminalach mogło dzielić czas mózgu jednego komputera. Kiedy twórcy Project Genie założyli firmę o nazwie Berkeley Computer Corporation (BCC), której celem było zbudowanie maszyny komercjalizującej ich pracę, Lampson zatrudnił Simonyi.

W BCC Simonyi przez całą noc debugował niezgrabny prototyp firmy, współpracując z projektantem systemu Chuckiem Thackerem. Pewnej nocy Simonyi pojawił się w prześwitującym czarnym stroju – coś w rodzaju hipisa z jednego ze sklepów na Telegraph Avenue, jak mówi. Dziś nie pamięta dokładnie, dlaczego – może pochodzący z imprezy? Debugowanie poszło szczególnie dobrze tej nocy, a strój stał się amuletem na szczęście — strój do debugowania Simonyi.

BCC podupadło zaledwie po kilku latach, ale Lampson, Thacker i znaczna część zespołu BCC przeszli do Xerox PARC. Simonyi – wtedy tylko przypadkowy węgierski licencjat bez zielonej karty, jak mówi teraz – dołączył do nich w 1972 roku, pracując w Xeroxie, jednocześnie robiąc doktorat w Stanford. Bob Taylor, który nadzorował laboratorium komputerowe PARC w części tej legendarnej epoki, mówi, że kreatywność Simonyi wyróżniała się nawet w słynnym tłumie laboratorium: po prostu potrafił wyobrazić sobie sposoby wyrażania kodu i pomysłów, które zepchnęły go z listy przebojów.

To był ciężki czas. Zespół wizjonerskich inżynierów tworzył szereg innowacji, które miały ukształtować następne ćwierć wieku ery PC: graficzny interfejs użytkownika, sieć (Ethernet), drukarka laserowa, programowanie obiektowe (Smalltalk), komputery przenośne (the Dynabook) i nie tylko. Wszystkie te przełomy zbiegły się w prototypowym komputerze osobistym o nazwie Alto.

Alto był niesamowitym wynalazkiem, ale nie było jasne, co można z nim zrobić, dopóki Simonyi i jego koledzy nie stworzyli jego najbardziej znanej aplikacji: edytora tekstu o nazwie Bravo, którego typ wyświetlany na ekranie odpowiadał temu, co system wyświetlał. do nowej drukarki laserowej. Istniejące procesory tekstu miały rozbudowane systemy kodów do formatowania tekstu na ekranie (każdy, kto używał WordPerfect na komputerze w latach 80., zapamięta jego kody osadzone); Bravo pozwala zapomnieć o kodach, bezpośrednio manipulować projektem dokumentu i od razu obserwować zmiany. Odwiedzający Citibank dyrektor obejrzał demo i zacytował charakterystyczną linię komika Flipa Wilsona, bezczelnego bohatera Geraldine: To, co widzisz, jest tym, co dostajesz! Nazwa (skrócona do akronimu Wysiwyg i wymawiana Wizywig ) zablokowany. Nagle Bravo zyskało użytkowników: krewni i przyjaciele badaczy PARC zaczęli prosić o wykorzystanie go do drukowania biuletynów szkolnych i formatowania artykułów naukowych. Żona Lampsona wydrukowała swoją pracę dyplomową za pomocą systemu, a kiedy nadszedł czas, aby Simonyi wydrukował swoją, zrobił to samo.

Poziomy abstrakcji

Wysiwyg jest przykładem warstwy abstrakcji — narzędzia wyższego poziomu, które pozwala użytkownikom komputerów zignorować część złożoności niższego poziomu. Programiści cały czas używają abstrakcji. Kod tekstowy napisany w języku programowania jest abstrakcją kodu maszynowego, który komputer faktycznie rozumie. Nazwa domeny internetowej jest abstrakcją numerycznego adresu protokołu internetowego serwera.

Ale większość warstw abstrakcji w systemach komputerowych jest mniej widoczna i bardziej tajemnicza niż Wysiwyg. Odkąd programiści przestali zapamiętywać kody operacyjne, których Simonyi używał w młodości, nakładali nowe abstrakcje na starsze abstrakcje. Każde pokolenie programistów wykorzystuje języki programowania i narzędzia swojej epoki do tworzenia programów następnej generacji. Warstwy abstrakcji skumulowały się jak warstwy geologiczne. Wiadomości nieustannie pędzą z binarnego podłoża komputera i z powrotem w dół, dzięki czemu możliwe jest kliknięcie myszą, aby wykonać swoją funkcję. Kliknięcie myszą uruchamia pewien kod w systemie operacyjnym, który wysyła komunikat do programu do edycji tekstu, który nakazuje systemowi operacyjnemu zapisanie pliku na dysku twardym. Ale ten pozornie prosty proces jest możliwy tylko dzięki wielu, wielu warstwom abstrakcji.

Historia oprogramowania to historia tych warstw, z których każda odsuwa programistów od binarnych, pozwalając im lepiej nakłaniać komputery do wykonywania użytecznych zadań. Programiści stopniowo zdobywali coraz większą władzę. Ale zajmowali się także coraz ambitniejszymi problemami. Programy rozrosły się, a programiści zaczęli gubić się w plątaninie tego, co nazywali kodem spaghetti, który okazał się niemożliwy do rozwikłania i naprawienia. W ten sposób duże projekty oprogramowania stały się epiką frustracji i opóźnień. Menedżerowie programów stanęli przed problemami biznesowymi, takimi jak: Jak realistycznie zaplanować projekt? Jak poprawić indywidualną produktywność? Jak koordynujesz złożoną pracę w dużym zespole? Na każde z tych pytań zaskakująco trudno było odpowiedzieć.

Trudność w koordynowaniu pracy zespołu zainspirowała najsłynniejsze powiedzenie inżynierii oprogramowania, znane jako prawo Brooksa: dodanie siły roboczej do późnego projektu oprogramowania sprawia, że ​​jest to później. Frederick P. Brooks Jr. doszedł do tego ponurego wniosku po tym, jak w latach 60. kierował trudnymi wysiłkami IBM w zakresie napisania oprogramowania dla komputerów mainframe 360. W swojej książce z 1975 roku Mityczny Człowiek-Miesiąc Brooks zauważył, że w większych zespołach praca przebiega wolniej z powodu kosztów koordynacji – czasu, jaki programiści tracą na wzajemnym informowaniu się o swojej pracy.

To było tło dla rozprawy Simonyi z 1977 roku, Meta-programowanie: metoda produkcji oprogramowania. Simonyi zaproponował nowe podejście do optymalizacji produktywności, w którym jeden główny programista lub metaprogramista zaprojektował produkt i zdefiniował wszystkie jego warunki, a następnie przekazał plan technikom, programistom-robotnikom, którzy mieliby wykonać wdrożenie. Simonyi starał się uciec przed prawem Brooksa, zabraniając technikom komunikowania się ze sobą: cała komunikacja musiała przechodzić przez meta-programistę. W swojej pracy doktorskiej przetestował ten pomysł na dwóch grupach w dwóch projektach, A i B. Jego despotyczne podejście do programowania nigdy się nie przyjęło, ale to go nie martwiło. Głównym celem Simonyi'ego w badaniu jego pracy doktorskiej nie było udowodnienie wartości jego pomysłów, ale przyspieszenie pisania Bravo, nowego edytora tekstu Wysiwyg. Nie mógł przekonać szefa PARC do zatrudnienia dodatkowych programistów, więc wykorzystał swoją rozprawę jako podstęp, aby sprowadzić pomoc. Samo Bravo było projektem B.

W miarę upływu lat 70. Simonyi zniecierpliwił się niezdolnością firmy Xerox do przekształcenia pionierskich badań PARC w udane produkty. Pewnego dnia przyjaciel pokazał mu VisiCalc, nowy program do obsługi arkuszy kalkulacyjnych dla Apple II. To zachwyciło Simonyiego. Oto kolejna aplikacja, taka jak Bravo, która może zmienić ludzkie życie, ale w przeciwieństwie do Bravo, działała na masowym komputerze, na który ludzie mogli sobie pozwolić. Zdał sobie sprawę, że praca PARC nigdy nie ujrzy światła dziennego. Poprosił swojego byłego kolegę z PARC, Boba Metcalfe, który opuścił laboratorium w 1979 roku, aby założyć firmę 3Com, aby zarekomendował potencjalnych szefów w raczkującej branży PC. Na czele listy był Bill Gates.

W 1981 roku Simonyi przeniósł się do Seattle, aby założyć grupę nowych aplikacji w firmie Microsoft, która do tej pory sprzedawała języki programowania i systemy operacyjne. Miał 33 lata, ale to uczyniło go dorosłym wśród młodych Microsoftu (Gates miał wtedy 26 lat, Steve Ballmer 25).

Przez wszystkie lata, kiedy Simonyi nadzorował produkty, które ostatecznie połączyły się w pakiet programów znany jako Microsoft Office, nadal poszukiwał nowych możliwości w nowych rodzajach abstrakcji programistycznych. Przede wszystkim szkolił pokolenia programistów Microsoft w dyscyplinie śledzenia niezliczonych nazw zmiennych używanych w dużych programach. W programowaniu komputerowym zmienne reprezentują informacje, które mogą się zmieniać podczas działania programu. Na przykład program koszyka na zakupy w sklepie internetowym będzie miał zmienne, które reprezentują liczbę przedmiotów każdego typu do kupienia, cenę każdego przedmiotu oraz koszty wysyłki i podatki. Korzystając z tych zmiennych, programista może napisać prosty wiersz kodu, który mnoży ilość przez cenę, dodaje koszty wysyłki i podatki oraz oblicza całkowity koszt — który staje się wartością jeszcze innej zmiennej.

Duży program może mieć tysiące różnych zmiennych, które zespół programistyczny musi zachować prosto. Ostrożne ich nazywanie staje się kluczowe. Obecnie większość kodu zawiera nazwy zmiennych, które mają przekazać znaczenie programistom, którzy go przeczytają — takie jak NumberOfItems lub ShoppingCartTotal. W schemacie nazewnictwa Simonyi, który wymyślił na własny użytek wiele lat wcześniej, każda nazwa zmiennej ma przedrostek, który zawiera przydatne informacje na jej temat, takie jak jej typ (liczba całkowita, powiedzmy, ułamek dziesiętny lub ciąg liter). Niektóre systemy ograniczają długość nazw zmiennych do ośmiu znaków; Simonyi po prostu pominął samogłoski.

Powstały kod był gęsty i trudny do odczytania. Według pioniera programowania Andy'ego Hertzfelda system Simonyiego stał się znany jako notacja węgierska, zarówno w hołdzie dla miejsca narodzin jego twórcy, jak i dlatego, że sprawiał, że programy wyglądały tak, jakby były napisane w jakimś niezbadanym języku obcym. Węgier jest powszechnie przeklęty przez swoich krytyków. Kanadyjski ekspert Javy, Roedy Green, żartobliwie nazwał to taktyczną bronią nuklearną technik zaciemniania kodu źródłowego. Programista Mozilli Alec Flett napisał tę parodię:

prepBut nI vrbLike adjwęgierski! qCo to jest sztukaAdjBig nProblem?

Hertzfeld, pisząc o spotkaniu w Apple z jakimś węgierskim kodem napisanym przez kolegę, który pracował z Simonyi w PARC, powiedział, że nazwy wyglądały, jakby zostały wybrane przez wroga Supermana z piątego wymiaru, pana Mxyzptlka.

Ale choć krytycy uważają, że język węgierski czyni kod nieczytelnym, Simonyi jest z niego dumny i stosuje go do dziś.

Meta-euforia

Na początku lat 90. sukces Microsoftu przyniósł fortunę Simonyiego. (Przez kilka lat, Forbes oszacował ją na 1 miliard dolarów.) Ale nadal czuł szarpnięcie niedokończonych spraw. Zamieszanie w oprogramowaniu sprawiło, że tworzenie pakietu Office było dla Microsoftu stresujące. Ale teraz, gdy na każdym biurku znajdują się komputery o większej mocy niż Alto, a Internet łączy je ze sobą, kryzys oprogramowania był kryzysem wszystkich. Simonyi zaczął myśleć, że nadszedł czas, aby ponownie przejść do meta.

Charles zawsze starał się budować swoje systemy w sposób, który podnosi poziom abstrakcji, tak abyś mógł zarządzać złożonością systemu. Ponieważ złożoność to śmierć, mówi Chuck Thacker, stary kolega Simonyi z BCC i PARC, który prowadzi projekt badawczy dotyczący architektury komputerowej w Microsoft. I niestety, w dzisiejszych czasach udostępnianie udogodnień, których ludzie rzeczywiście chcą, daje w rezultacie złożony system. W tej chwili trzymamy się na opuszkach palców.

Przechodząc na stanowisko w Microsoft Research, Simonyi zaczął definiować pojęcie programowania zamierzonego, w skrócie IP. Programowanie intencjonalne dodałoby zupełnie nową warstwę abstrakcji do praktyki pisania oprogramowania. Umożliwiłoby to programistom wyrażenie swoich intencji bez zapadania się w bagno tak zwanych szczegółów implementacyjnych, które zawsze groziły ich połknięciem. Podobnie jak meta-programiści z rozprawy Simonyi, przekazujący instrukcje programistom-robotnikom, umyślny programista przekazywałby pracę — ale nie młodszemu koledze. Zamiast tego celowe programowanie wymagało pewnego rodzaju fabryki kodu zwanej generatorem, programu, który przyjmuje zestaw stosunkowo wysokopoziomowych poleceń i wypluwa bardziej szczegółowy działający kod. Celem było nie tyle ułatwienie pracy związanej z programowaniem, co umożliwienie programistom oczyszczenia mózgów z błahości, aby mogli faktycznie być kreatywni.

Od czasu rozpoczęcia programowania jako nastolatek, wbijający kody na Uralu, Simonyi wspinał się po drabinie abstrakcji. Ale czuł, że nie był wystarczająco wysoki. Pod wieloma względami programowanie wciąż wydawało się prymitywne. Dlaczego programiści wciąż byli obarczeni niekompatybilnymi składniami języka programowania? Dlaczego tak trudno było rozszerzyć ich preferowane języki na nowe obszary? Dlaczego programiści nadal pracowali ze zwykłym tekstem, układając niewielką liczbę znaków w ciągi liniowe, tak jak miało to miejsce w przeszłości kart dziurkowanych? Praca Wysiwyga Simonyi'ego umożliwiła pracownikom biurowym tworzenie i edycję skomplikowanych dokumentów. Inżynierowie i projektanci używali zaawansowanych narzędzi CAD/CAM do projektowania i modyfikowania planów drapaczy chmur i samolotów. Dlaczego programiści, czarodzieje, którzy to wszystko umożliwili, wciąż wydziobali swój kod znak po znaku?

Jego zespół Microsoft Research zabrał się do pracy i do marca 1995 roku zbudował działający system do konstruowania programów przy użyciu podejścia programowania zamierzonego. Simonyi powiedział, że IP osiągnęło całkowitą samowystarczalność: to znaczy, że cała przyszła praca nad IP będzie wykonywana przy użyciu samego IP. Nagrodził swoją drużynę koszulkami ozdobionymi jednym z jego ulubionych zdjęć z dzieciństwa: obrazem barona Munchausena wyciągającego siebie i konia z bagna, szarpiąc za własne włosy. Simonyi ogłosił światu celowe programowanie w artykule z września 1995 roku zatytułowanym The Death of Computer Languages. Nadszedł czas, jak to później ujął, aby dzieci szewca zaopatrzyły się w buty.

Przez lata 90. aż do nowego tysiąclecia — podczas gdy Microsoft toczył wojny z Netscape i Departamentem Sprawiedliwości Stanów Zjednoczonych oraz wyszedł z bańki internetowej i bankructwa — Simonyi i jego zespół pracowali i uczyli się.

W międzyczasie, począwszy od 2001 roku, Microsoft naciskał na armie programistów, którzy napisali oprogramowanie dla systemu Windows, aby zaadoptowali nowy system programowania o nazwie .Net Framework. W przeciwieństwie do programowania celowego, .Net został ukończony i wymagał mniej radykalnego zerwania z istniejącymi technikami programowania. Simonyi chciał wynieść swój pomysł z laboratorium i przedstawić go klientom, ale w tych okolicznościach było to niezręczne. Wyjaśnia: To było niepraktyczne, kiedy Microsoft poczynił ogromne postępy w .Net w bliskiej perspektywie, aby jakoś wysłać kogoś z tej samej organizacji, która mówi: „To nie tak powinno się robić rzeczy – a co, jeśli robiłeś coś w tej drugiej , bardziej destrukcyjny sposób?

Simonyi był pracownikiem firmy od ponad 20 lat. Ale w 2002 roku opuścił Microsoft i założył niezależną firmę. Wyszedł z umową licencyjną dotyczącą patentów, która pozwoliła mu wykorzystać koncepcje i idee jego badań nad programowaniem zamierzonym, ale nie pozwoliła mu zabrać ze sobą części starego kodu. Musiałby zacząć pisać nową bazę kodu od zera.

Pod szyldem swojej nowej firmy Simonyi porzucił słowo programowanie i przemianował swój projekt na oprogramowanie celowe. Podstawowa idea się nie zmieniła, ale teraz zaczął podkreślać wartość podejścia dla nieprogramistów. Ton Simonyiego wyglądał mniej więcej tak: Dzisiaj tylko programista może mieć bezpośredni wpływ na oprogramowanie. Eksperci w danej dziedzinie lub eksperci dziedzinowi – ludzie, którzy faktycznie rozumieją, co oprogramowanie musi robić, czy jest to prowadzenie dokumentacji medycznej, księgowość korporacyjna czy modelowanie klimatu – nie mogą wprowadzać zmian w swoich narzędziach; są zmuszeni do wysłania do programisty swego rodzaju skromnej prośby. Firma Intentional Software sprzedawałaby narzędzia do tworzenia oprogramowania nie tylko programistom, ale także ekspertom dziedzinowym, którzy naprawdę znali swoje dziedziny.

Strategia Intencjonalnego oprogramowania zapożycza się z trendu w programowaniu znanego jako języki specyficzne dla domeny lub DSL – małe dialekty programowania dostosowane do potrzeb określonych dyscyplin. Simonyi chwali DSL, ale mówi, że nie idą wystarczająco daleko. Są trudne do stworzenia, a zatem kosztowne; w końcu potrzebujesz więcej niż jednego (w przypadku systemu rozliczeń medycznych potrzebujesz przynajmniej języka medycznego i finansowego); i są ze sobą niezgodne. System Intencjonalnego oprogramowania jest jak fabryka dla wielu DSL, które mogą się ze sobą komunikować.

Oto, jak to może działać: załóżmy, że międzynarodowy bank chciałby opracować nowy system do zarządzania transakcjami w wielu walutach. Po pierwsze, eksperci dziedzinowi banku określiliby funkcjonalność systemu, używając swoich zwyczajowych terminów i symboli oraz identyfikując najważniejsze zmienne (czas lub wartość lub wielkość transakcji) oraz najczęstsze procedury (przeliczanie zasobów z jednej waluty na inną lub zabezpieczenie zakupu przed spadkiem wartości). Następnie programiści wzięliby te informacje i zbudowali generator programu specyficznego dla domeny, który zawiera te informacje. Oddzielne narzędzie programowe pozwoliłoby ekspertom z danej dziedziny na eksperymentowanie z różnymi zestawami danych i sposobami przeglądania tych danych tak łatwo, jak dziś biznesmeni przestawiają swoje arkusze kalkulacyjne.

Programista nie musiałby być wzywany za każdym razem, gdy jakaś nowość w świecie bankowości międzynarodowej lub jakakolwiek inna dziedzina wymagałaby nowej funkcji oprogramowania. Klient nie czułby się przygnieciony językiem programowania. Wszyscy byliby szczęśliwi.

Simonyi twierdzi, że jego podejście rozwiązuje kilka najbardziej uporczywych problemów inżynierii oprogramowania. Często mówi, że dzisiejsi programiści są nieświadomymi kryptografami: zbierają wymagania i wiedzę od swoich klientów, a następnie dosłownie ukrywają te cenne informacje w górze szczegółów implementacji – to znaczy kodu. Haczyk polega na tym, że po napisaniu kodu programiści muszą wprowadzać wszelkie dodatki lub zmiany poprzez modyfikację sam kod . Ta praca jest bolesna, powolna i podatna na błędy. W ogóle nie powinniśmy dotykać kodu, mówi Simonyi. Powinniśmy być w stanie zaprojektować funkcje i struktury danych — które programowanie intencjonalne przedstawia jako drzewa intencjonalne — i pozwolić generatorowi odpowiednio zmodyfikować kod. (Aby uzyskać pełniejszy opis programowania celowego, zobacz Wyjaśnienie programowania zamierzonego )

W 2002 roku Simonyi zebrał nowy zespół programistów; dziś obejmuje kilkunastu programistów, podzielonych między Bellevue i Węgry. Zaczęli ponownie tworzyć od podstaw kod do celowego programowania Simonyi i współpracować z garstką klientów, aby przetestować ich założenia i uzyskać informacje zwrotne. Rok temu, zainspirowani nowym spojrzeniem na sposób prezentowania wielu widoków heterogenicznych typów danych, wyrzucili dużo swojego kodu i zaczęli od nowa. To twórcza destrukcja, mówi Simonyi. W Microsoft było to dość trudne, aby wszystko wyrzucić. Ale musisz porzucić rzeczy, które są trudne do wydłużenia.

ThoughtWorks, globalna firma konsultingowa w dziedzinie IT, jest jednym z wczesnych klientów Intentional Software. Ale dyrektor generalny ThoughtWorks, Roy Singham, mówi, że wielu jego kolegów z firmy początkowo było sceptycznie nastawionych do nowego projektu Simonyi: Wiele osób patrzy na to i mówi: „Genialny pomysł, ale nie da się go wdrożyć”. najlepsze techniczne mózgi do obejrzenia, a wszyscy wrócili i powiedzieli, że jest na dobrej drodze. Tak, to trudne. Tak, to zajmie trochę czasu – może wiele lat. Ale intelektualnie ma to wszystko przybite. To właściwy problem do rozwiązania.

Czułem pewną frustrację, że nie mamy jeszcze czegoś, co moglibyśmy wykorzystać w produkcji, mówi Martin Fowler, główny naukowiec w ThoughtWorks. Wygląda na to, że Charlesowi nie spieszy się z wysyłką. Ale jedną rzeczą, o której należy pamiętać, jest to, że wysyłał rzeczy w przeszłości – dość dramatyczne rzeczy, z pakietem Office.

Widocznym owocem dotychczasowej pracy firmy Intentional jest sprytne narzędzie o nazwie Domain Workbench, które przechowuje ważne informacje o programie w bazie danych drzewa intencjonalnego, a następnie oferuje wiele różnych projekcji tych informacji. Podczas demonstracji, jaką firma Intentional wygłosiła na dwóch konferencjach zeszłej jesieni, Workbench — korzystając z funkcji zwanej Kaleidoscope — pobrał serię fragmentów kodu i wyświetlił je w oszałamiającej różnorodności formatów. Nie miało znaczenia, jak określono składnię kodu; możesz go wyświetlić i zmienić, używając dowolnej preferowanej notacji. Możesz edytować swój program jako tradycyjny kod w nawiasach i wciętych lub przejść do formy konspektu, lub sprawić, by wyglądał jak schematyczny diagram instalacji elektrycznej, lub wybrać coś, co nazywa się diagramem kolejowym, rodzaj notacji schematów blokowych wywodzącej się ze staromodnych map pociągów . Każdy widok jest tłumaczeniem podstawowego drzewa, które można również przeglądać i edytować.

Praca firmy Intentional Software prowokuje dwie główne linie krytyki. Niektórzy sceptycy teoretycznie myślący twierdzą, że cel Simonyi, jakim jest uchwycenie intencji użytkowników komputerów, jest nieprawdopodobny. Jak reprezentujesz intencje? pyta informatyk Jaron Lanier. Gdy tylko dowiemy się, w jaki sposób mózg przechowuje informacje, może będziemy mogli reprezentować intencję. Dla mnie to po prostu wydaje się fantazją. Kolejny argument, powszechny wśród programistów, jest bardziej praktyczny. Wielu programistów kocha swoje edytory tekstowe i nie ma zaufania do narzędzi, które oddalają ich od surowego kodu. Jeśli chodzi o graficzne języki programowania, takie jak Visual Basic i zintegrowane środowiska programistyczne (IDE), które automatyzują rutynowe zadania programistyczne, traktują je z protekcjonalnością: takie narzędzia, jak mówią, narzucają własne sposoby działania, ograniczają kreatywność i powstrzymują programistów od kod, z którym prędzej czy później będą musieli się skonfrontować. (Aby zrozumieć, dlaczego programiści są tak ostrożni, zobacz Prawo nieszczelnych abstrakcji ) Sceptyczni programiści patrzą na oprogramowanie intencjonalne i widzą perspektywę kolejnego IDE. Dla tych, którzy uważają, że prawdziwi programiści piszą tekst, programowanie celowe nie jest ani bardzo oryginalne, ani zbyt pożądane.

Ale przede wszystkim na internetowych forach programistycznych jest zaskakująco mało dyskusji na temat oprogramowania zamierzonego. Po części dlatego, że tak niewielu widziało jego oprogramowanie. Prace Intentional przebiegały w pewnej tajemnicy.

Kiedy zakładał Intentional Software, Simonyi współpracował z Gregorem Kiczalesem, profesorem Uniwersytetu Kolumbii Brytyjskiej. Simonyi podziwiał pracę Kiczalesa nad programowaniem aspektowym – sposobem organizowania i modyfikowania kodu zgodnie z przekrojowymi problemami, który przypomina programowanie celowe. Kiczales, kolejny weteran PARC, spędził swoją karierę na pracy nad sposobami, aby kod wyglądał jak projekt. Kiczales widział w dołączeniu do Simonyi szansę na dalsze osiągnięcie tego celu. Ale Kiczales zaufał rozwojowi open source, w przeciwieństwie do Simonyi. Podejście do zamkniętego sklepu w stylu Microsoftu po prostu nie było dla Kiczalesa organiczne. Zrobiłbym to w Javie, mówi. Pierwsze wydanie miałoby nastąpić za sześć miesięcy. Spór był przyjacielski, ale nie do pogodzenia, jak mówią obaj mężczyźni, i wkrótce Kiczales wyszedł.

Na razie, chronione bogactwem Simonyi, Intentional Software nie ma docelowej daty ani terminu wysyłki. Ale jeden z jej dwóch głównych klientów twierdzi, że jest blisko wdrożenia narzędzi Intentional. Capgemini — międzynarodowa firma świadcząca usługi IT i konsultingowa z siedzibą w Paryżu, obsługująca duże przedsiębiorstwa, której CTO, Andy Mulholland, znajomy Simonyi’s, rozpoczęła współpracę z Intentional w marcu zeszłego roku i rozważa wykorzystanie systemu Intentional do projektów w europejskim biznesie emerytalnym. Jak mówi Henk Kolk, dyrektor ds. technologii usług finansowych w Capgemini, kierujący współpracą firmy z firmą Intentional, sprawiają, że podejście firmy Simonyi wygląda atrakcyjnie, ponieważ bardzo złożone zasady w tej dziedzinie przeplatają się ze złożoną strukturą domeny biznesowej.

Kontrola naziemna

Fascynacja Simonyi przestrzenią trwała przez całe życie. Jako 13-latek wygrał konkurs na węgierskiego młodszego astronautę i pojechał do Moskwy na spotkanie z kosmonautą. Jako nowy pracownik firmy Microsoft w 1981 r. przekonał współzałożyciela Paula Allena, by pobawił się w rozwijanie nowego systemu operacyjnego IBM PC i poleciał na Florydę, aby obejrzeć pierwszy lot wahadłowca kosmicznego.

Nadchodząca eksplozja Simonyi'ego oferuje mu pełne spotkanie z technologią z czasów sowieckich, która wyznaczyła kurs jego życia. Od miesięcy trenuje w rosyjskim Centrum Szkolenia Kosmonautów im. Jurija Gagarina w Star City, doskonaląc szczegóły skafandrów kosmicznych i kosmicznych toalet oraz ucząc się rosyjskiego.

Kosmiczna podróż potwierdzi status Simonyi jako wysoce nieprawdopodobnej rzeczy: programisty celebrytów. Ma dwa odrzutowce i licencję pilota na ich latanie. Pojawia się w tabloidach jako częsty towarzysz arcykapłanki zajmującej się prowadzeniem domu, Marthy Stewart. Zbudował 233-stopowy jacht z owiniętym szklanym pokładem. Ufundował profesurę w Oksfordzie dla swojego przyjaciela Richarda Dawkinsa, teoretyka darwinizmu.

Nic z tego oczywiście nie wpłynie na wynik dążeń Simonyi do złagodzenia chronicznych nieszczęść w dziedzinie oprogramowania. Nie wystarczy być świetnym programistą, powiedział kiedyś Simonyi Michaelowi Hiltzikowi, autorowi historii PARC. Musisz znaleźć wielki problem. Intencjonalne może nigdy nie dotrzymać swoich wielkich obietnic. Ale nikt nie może oskarżyć Simonyiego o wybranie zbyt skromnego problemu.

Obecnie jego domem jest rezydencja nad jeziorem Washington, położona na brzegu od domu Billa Gatesa, z galerią sztuki, przeszklonym basenem, lądowiskiem dla helikopterów, laboratorium komputerowym ze ścianami wyłożonymi magnetycznie oraz tokarką i wiertarką w piwnica (aby spełnić te pragnienia Erector Set). Budowa domu kosztowała 10 milionów dolarów: jest przechylony pod kątem siedmiu stopni i wygląda, jakby uderzyło go lekkie trzęsienie ziemi. New York Times pisarka Patricia Leigh Brown, która zachwycała się jej hermetycznie zamkniętą, matematyczną precyzją i odkryła, że ​​jest tak ogromna, że ​​zwiedzający może poczuć się jak samotna asteroida turkocząca wokół Układu Słonecznego.

[Tylko] Charles zbudowałby dom o powierzchni 20 000 stóp kwadratowych z jedną sypialnią, zauważył kiedyś doradca Simonyi i kolega z PARC Butler Lampson. W samotnej sypialni znajduje się podobne do kokpitu centrum sterowania, które pozwala Simonyi na dostosowywanie wszystkich swoich systemów – ogrzewania, rozrywki, telefonu, oświetlenia i nawadniania – zgodnie z jego satysfakcją. Jak łódź podwodna, wyjaśnił Brownowi. Wszystkie muszą być zielone, zanim się zanurzysz. Jest też obrotowe łóżko, za pomocą którego Simonyi może dostroić swój widok na jezioro; albo na panoramę Seattle, z labiryntami pracowników biurowych zmagających się z dokumentami i arkuszami kalkulacyjnymi; albo w gwiaździste nocne niebo, gdzie niedługo zabierze go jego ostatnia podróż.

Scott Rosenberg jest wiceprezesem ds. projektów specjalnych w Salon.com. Jest autorem Śnienie w kodzie.

Wyjaśnienie celowego programowania
Simonyi i spółka są pionierami w programowaniu opartym na przyciskach.

[ Kliknij tutaj za schemat planowanego podejścia Simonyiego]

Shane Clifford, programista w Intentional Software, opowiada tę bajkę.

Kiedyś istniała wieś z czterema parkami, utrzymywana przez cztery konkurencyjne stowarzyszenia sąsiedzkie. Pierwsze stowarzyszenie postanowiło urozmaicić swój park nową ławką. Pozyskał propozycje od trzech czołowych producentów ławek na świecie. Żaden z projektów nie zdobył większości głosów sąsiadów, więc stowarzyszenie wybrało najpopularniejszy projekt. Proces był demokratyczny, ale ostatecznie większość była niezadowolona z nowej ławki.

Drugie stowarzyszenie zdecydowało, że chce mieć własną ławkę, ale taką, która wszystkim się podoba. Znalazł producenta, który zbudował niestandardowe ławki z części mieszanych i dopasowujących. Ale drewniane siedzisko, które lubili członkowie, nie miało odpowiedniej długości, a ozdobne oparcie nie pasowało do zielonych nóg, które lubili. Więc poszli na kompromis, jeśli chodzi o części, które ze sobą współpracowały. Sąsiedzi byli dumni z gotowej ławki, ale nikt często na niej nie siadał.

Członkowie trzeciego stowarzyszenia zobaczyli, ile pieniędzy wydali dwaj pierwsi, i zdecydowali, że mogą zrobić to lepiej. Rzemieślnicy w grupie poprosili wszystkich o sugestie, a na koniec zbudowali prostą, elegancką ławkę, która według wszystkich była najładniejsza w wiosce. Niestety, niebezpiecznie się zachwiał.

Czwarte stowarzyszenie też chciało ławki, ale nie chciało powtarzać błędów innych grup. Sąsiedzi zwrócili się do mało znanego producenta ławek, który reklamował nowe doświadczenie z ławkami. Przyjechał ławiec z ciężarówką z platformą załadowaną dziwnie wyglądającymi maszynami. Zaczął zadawać pytania typu Co jest najważniejszą cechą tej ławki? Jaka jest kolejna najważniejsza funkcja? Jakie materiały lubisz? Jaki jest Twój ulubiony kształt stóp na ławce?

Po każdej odpowiedzi wytwórca ławek przekręcał kilka pokręteł na swoich maszynach, a na dużym ekranie pojawiał się nowy obraz ławki w toku. Czasami obraz nie był całkiem odpowiedni, więc sąsiedzi cofali się i odpowiadali na pytania inaczej. Po 50 pytaniach ławkarz nacisnął duży przycisk. Maszyny przez chwilę brzęczały, po czym wypluły piękną ławkę pasującą do końcowego obrazu na ekranie. Wszyscy cieszyli się, że mieli szansę wnieść swój wkład, a wiele osób codziennie siadało na ławce.

Aby uzyskać ławkę, która uszczęśliwi wszystkich, musisz zbudować automatyczną maszynę do robienia ławek; pomóc klientom sprecyzować ich nadzieje na ławkę; przełożyć te nadzieje na instrukcje, które rozumie maszyna do robienia ławek; a następnie naciśnij przycisk Utwórz. Klienci uzyskują ścisłą kontrolę nad rezultatem, a twórcy ławek, uwolnieni od powtarzalnych i mechanicznych elementów tworzenia ławek, mogą spędzać więcej czasu, wykorzystując swoje umiejętności, aby wprowadzić życzenia klientów do maszyny.

Zastąp oprogramowanie ławkami, mówi Clifford, a zrozumiesz programowanie celowe – nazwane tak, ponieważ programiści koncentrują się na sposobie, w jaki ich klienci chcą, aby program działał, a nie na bałaganie kodu wymaganego do realizacji tych zamiarów.

Programowanie intencjonalne jest podobne w swojej koncepcji do programów do przetwarzania tekstu „co-widzisz-to-co-dostajesz”, których pionierem był Charles Simonyi, szef Clifforda. Edytory tekstu Wysiwyg pozwalają użytkownikom komputerów manipulować wyglądem dokumentu na ekranie bez zmuszania ich do opanowania podstawowego kodu. Podobnie programowanie celowe zachęca użytkowników komputerów do wyrażania swoich potrzeb w znanym im języku, a następnie pokazuje im zrozumiałe widoki lub projekcje powstającego projektu, zanim zostanie zmontowany kod wykonywalny. To nie jedyna filozofia programowania, która opiera się na takich graficznych reprezentacjach; Unified Modeling Language (UML), opracowany w połowie lat 90. w Rational Software (obecnie część IBM), również wykorzystuje diagramy graficzne do reprezentowania funkcji, struktury i zachowania programu. Ale diagramów UML nie da się przekształcić w gotowe oprogramowanie, co jest marzeniem Simonyi o programowaniu celowym.

Jak Intentional Software ma nadzieję zrealizować to marzenie? Umieśćmy plan Simonyiego na własnym diagramie (kliknij tutaj). Proces tworzenia oprogramowania zaczyna się naturalnie od klienta: dowolnej organizacji, której zadanie wymagające dużej ilości informacji wymaga automatyzacji. Simonyi nazywa ludzi w tych organizacjach ekspertami dziedzinowymi; to oni, a nie programiści, wiedzą, co program powinien zrobić.

Z pomocą programistów eksperci dziedzinowi wymieniają wszystkie pojęcia i definicje, które oprogramowanie będzie musiało obejmować. Wszystkie te definicje trafiają do bazy danych, którą Simonyi nazywa schematem domeny.

Podobnie jak twórca ławek obracający gałkami, programiści włączają następnie definicje ze schematu domeny do kodu domeny – reprezentacji wysokiego poziomu funkcji oprogramowania, wyrażonej w języku specyficznym dla domeny lub DSL, który można dostosować do potrzeb branża, o której mowa. Ale chociaż łącza DSL mogą się różnić, każda czynność, którą musi wykonać oprogramowanie, jest przechowywana w jednolitym formacie, zamierzonym drzewie. Zamierzone drzewa mają tę zaletę, że są wizualnie proste, ale logicznie wszechstronne, co oznacza, że ​​można nimi dowolnie manipulować, poprawiać i projektować lub zmieniać ich wizję.

Na przykład obliczenia reprezentowane przez prostą instrukcję programu

zwróć a = b / (c +1) ;

jest reprezentowane przez następujące drzewo celowe:

Powrót
(

Przydzielać
(

do,
Div
(

b,
Jeszcze
(

C,
jeden

)

)

)

)

Po zakodowaniu w formie drzewa obliczenia można rzutować na wiele innych sposobów, które mogą być bardziej znane ekspertom dziedzinowym, na przykład

b
zwróć a = ——- ;
c + 1

Jako pierwsze konkretne zadanie, Simonyi i jego koledzy z Intentional Software pracują nad stworzeniem specjalnego narzędzia, Domain Workbench, zaprojektowanego do zarządzania tymi projekcjami. Zarówno eksperci domeny, jak i programiści używają środowiska pracy domeny do edycji i ponownej edycji prognoz, aż będą wyglądać prawidłowo. Następnie kod domeny jest wprowadzany do generatora — odpowiednika masy maszyn warsztatowych — który generuje kod docelowy w języku takim jak C++ lub Java, który inne komputery są w stanie zrozumieć, skompilować i uruchomić.

Po wygenerowaniu kodu docelowego nie można go z powrotem przekształcić w kod domeny. Pod tym względem generator przypomina program szyfrujący, który nieodwracalnie przekształca tekst jawny w tekst zaszyfrowany.

Jednak — i jest to prawdopodobnie największa zaleta celowego programowania — łatwo jest usunąć stary kod docelowy i wygenerować ulepszony kod od zera. Po prostu zrewiduj kod domeny za pomocą edytora Wysiwyg w Domain Workbench i uruchom go ponownie przez generator. W większości starszych podejść nawet najmniejsza zmiana pierwotnych założeń może wymagać od programistów przesiewania milionów wierszy kodu i ręcznego aktualizowania każdego wystąpienia koncepcji, definicji lub obliczeń.

Generator pozostaje największą czarną skrzynką w procesie Intentional Software. W publikacjach technicznych wszystko, co firma powie o tym tajemniczym komponencie, to to, że prototyp jest pisany w języku programowania C# Microsoftu i że uzyskuje dostęp do schematu domeny i kodu domeny za pomocą interfejsu programowania aplikacji, sposób na komunikację dwóch programów, który jest wbudowany w środowisko pracy domeny. Jasne jest jednak, że napisanie samego generatora lub dostosowanie go do konkretnej branży lub DSL będzie stanowić dużą część kosztów każdego projektu celowego programowania.

Wysiwyg umożliwił milionom kolejnych użytkowników tworzenie świetnie wyglądających dokumentów, pisze Simonyi na swoim blogu. Czas zrobić to samo dla użytkowników oprogramowania.

Wade Roush

Prawo nieszczelnych abstrakcji
Wyciąg z Dreaming in Code: Dwóch tuzinów programistów, trzy lata, 4732 błędów i jedno poszukiwanie oprogramowania transcendentnego , autorstwa Scotta Rosenberga, publikowane przez
Księgi koronne w styczniu 2007 r.

Oprogramowanie, jak widzieliśmy, składa się z warstw, a każda warstwa tłumaczy informacje i procesy dla warstw powyżej i poniżej. Na dole tego stosu warstw znajduje się maszyna z czystymi binarnymi jedynkami i zerami. Na szczycie znajdują się istoty ludzkie, budujące i wykorzystujące te warstwy. Intencjonalne oprogramowanie Simonyi, w głębi duszy, po prostu proponuje jeszcze jedną warstwę między maszyną a nami.

Warstwy oprogramowania są jego istotą i to one napędzają postęp w tej dziedzinie, ale mają uporczywą słabość. Przeciekają. Na przykład użytkownicy wielu wersji systemu Microsoft Windows są ze znużeniem zaznajomieni ze zjawiskiem niebieskiego ekranu śmierci. Pracujesz w jakiejś aplikacji, takiej jak przeglądarka internetowa lub Microsoft Word, i nagle, nie wiadomo skąd, twój ekran staje się niebieski i widzisz na nim biały tekst, który brzmi mniej więcej tak:

Wystąpił fatalny wyjątek 0E w
0167: BFF9DFFF.

Obecna aplikacja zostanie zamknięta.

Patrząc na monochromatyczny wygląd ekranu i blokowy krój pisma, weterani mogą wyczuć, że zostali cofnięci w czasie komputerowym. Niektórzy mogą nawet zrozumieć, że alarmujące odniesienie w wiadomości do krytycznego wyjątku oznacza, że ​​program napotkał błąd, którego nie może naprawić i uległ awarii, lub że tajemnicze liczby szesnastkowe (podstawa 16) opisują dokładną lokalizację w pamięci komputera, w której nastąpiła awaria odbyła się. Żadna z informacji nie ma żadnej wartości dla większości użytkowników. Zniknął wygodny, znajomy interfejs aplikacji, z której korzystali; głębsza warstwa abstrakcji – w tym przypadku powłoka systemu Windows lub program sterujący niższego poziomu – wybuchła jak pochylona warstwa skały macierzystej wystająca z nowszych warstw geologicznych na światło słoneczne.

(Ponieważ niebieski ekran śmierci jest kłopotliwy, w rzeczywistości stanowił wielki postęp w stosunku do wcześniejszych wersji systemu Windows, ponieważ czasami pozwala użytkownikowi zamknąć szkodliwy program i kontynuować pracę. Przed niebieskim ekranem prawie zawsze awaria jednego programu Windows usunął całą maszynę i wszystkie jej programy.)

W eseju zatytułowanym The Law of Leaky Abstractions Joel Spolsky napisał: Wszystkie nietrywialne abstrakcje są do pewnego stopnia nieszczelne. Abstrakcje zawodzą. Czasem trochę, czasem dużo. Jest wyciek. Sprawy idą źle. Dla użytkowników oznacza to, że czasami twój komputer zachowuje się w dziwaczny, kłopotliwy sposób, a czasami będziesz chciał, jak powiedział Mitch Kapor w swoim Manifest projektowania oprogramowania , wyrzuć to przez okno. Dla programistów oznacza to, że nowe narzędzia i pomysły, które łączą trochę złożoności obliczeniowej niskiego poziomu i pakują ją w nową, łatwiejszą do manipulowania abstrakcją, są świetne, ale tylko do czasu, gdy się zepsują. Wtedy cała ta ukryta złożoność wraca do ich pracy. Teoretycznie nowa, poręczna górna warstwa pozwala programistom zapomnieć o bałaganie pod nią; w praktyce programista musi jeszcze zrozumieć ten bałagan, bo w końcu w nim wyląduje. Spolsky napisał:

Abstrakcje tak naprawdę nie upraszczają naszego życia tak bardzo, jak powinny. … Prawo nieszczelnych abstrakcji oznacza, że ​​kiedy ktoś wymyśli nowe, pomysłowe narzędzie do generowania kodu, które ma nas wszystkich uczynić bardziej wydajnymi, słyszysz wiele osób mówiących: „Najpierw naucz się to robić ręcznie, a potem użyj narzędzia wizy, aby zaoszczędzić czas. Narzędzia do generowania kodu, które udają, że coś wyabstrahują, na przykład wszystkie abstrakcje, przecieki, a jedynym sposobem kompetentnego poradzenia sobie z przeciekami jest poznanie, jak działają abstrakcje i co one abstrahują. Zatem abstrakcje oszczędzają nam czas pracy, ale nie oszczędzają czasu na naukę. … A to wszystko sprawia, że ​​paradoksalnie, nawet jeśli mamy coraz wyższe narzędzia programistyczne z coraz lepszymi abstrakcjami, coraz trudniej jest zostać biegłym programistą.

Więc chociaż abstrakcje, które stworzyliśmy przez lata, pozwalają nam radzić sobie z nowymi porządkami złożoności w tworzeniu oprogramowania, z którymi nie mieliśmy do czynienia dziesięć czy piętnaście lat temu, i chociaż te narzędzia pozwalają nam uzyskać wiele pracy wykonanej niewiarygodnie szybko, napisał Spolsky, nagle pewnego dnia musimy rozwiązać problem, w którym abstrakcja wyciekła, a zajmuje to dwa tygodnie.

Prawo nieszczelnych abstrakcji wyjaśnia, dlaczego tak wielu programistów, z którymi rozmawiałem, sceptycznie przewraca oczami, gdy słyszą opisy programowania intencjonalnego lub inne podobne pomysły na przekroczenie złożoności oprogramowania. Nie chodzi o to, że nie chcieliby zrobić kolejnego kroku w drabinie abstrakcji; ale obawiają się, że bez względu na to, jak wysoko wejdą po tej drabinie, zawsze będą musieli biegać po niej częściej, niż by chcieli – a im wyższa się stanie, tym dłuższa podróż.

ukryć