Przyszłość programowania, wspomnienia z PDC

Z konferencji co prawda już wróciłem, ale głowa jest tęga od wspomnień a notatnik pełen różnorakich zapisów. Jedna z sesji na PDC, która będę długo pamiętał to panel dyskusyjny “Microsoft perspectives on the Future of programming”.

Polecam tę prezentację z całego serca. Pomimo, że mało dotykała przyszłości to nie pożałujecie ani minuty. Tytuł myli, bo ten panel to czysta synteza naszych aktualnych osiągnięć i dysputa nad bieżącymi problemami i głównymi nurtami w programowaniu.

Polecam tę prezentację głównie jako skarbnicę złotych myśli i zabawnych cytatów od bądź co bądź ciekawych person w świecie programowania i Microsoftu.

Aby dać wam parę przykładów. Pierwszy temat jaki wyszedł to współbieżność i programowanie równoległe. Burton Smith z tego co kojarzę ujął tę kwestię w trzech prostych słowach na S: “Stripe, stream or struggle”. Temat programowania równoległego ciągnął się przez solidny kawałek tej sesji. Burton ciągnął dalej, że dla niego jednym z tematów na przyszłość to dalsze ułatwienie tworzenia kodu równoległego bez potrzeby łamania go (na wątki, synchronizację, etc). Aby programiści przyzwyczajeni do sekwencyjnego wykonywania kodu mogli bez większych zmian swoich przyzwyczajeń wykorzystać moc wielu rdzeni.

Kolejny temat bardzo ważny jaki omawiano to transakcje. Tutaj znowu kolejna złota myśl: “Transactions are like fairy dust”. Z takich komentarzy później oczywiście tłumaczonych śmiałem się po pachy co trochę. Komentarze panelistów w tej kwestii raczej się uzupełniały:
Burton Smith stwierdził, że to bardzo ważny element abstrakcyjny w kodzie. Jeffrey Snover dodał, że to dla niego to główna metoda obudowania scenariuszy idzie dobrze/idzie źle. Herb Sutter dodał, że gwarantuje spójność obiektów i rollback zgodny z zależnościami.

To oczywiste oczywistości można by rzec, natomiast swobodny tok wypowiedzi pociągnął temat transakcji dalej już w stwierdzenie Butlera Lampsona, że transakcje aby działały muszą być małe. Duże transakcje po prostu nie działają, właśnie ze względu na blokady jakie wywołują. Tutaj już Herb Sutter poddał tę kwestię pod dyskusje wytaczając swoje argumenty dla działających równie dobrze dużych transakcji. To był bardzo ciekawy moment.

Kolejnym bardzo ciekawym tematem była dyskusja, którą ujmę krótko: typy nazwane vs. dynamiczne typowanie. Jeffrey jako twórca Powershell był tutaj silnym zwolennikiem języków dynamicznych. Pozostali przepuścili nagły atak na niego, co było bardzo ciekawe :)
Znów w tak ożywionej dyskusji padały ciekawe złote myśli. Któryś z panelistów rzucił hasło, że języki dynamiczne są bardzo błędogenne. Jeffrey miał kontr-argumenty. Bardzo szybko padło na aplikacje WWW, wtedy Butler znów w swoim stylu szybko uciął “że w aplikacjach WWW błędy generowane przez języki dynamiczne nie są złe, w końcu aplikacje WWW mają milion innych powodów aby nie działać” . To jeden z tych tekstów, przy których cała sala wybuchała śmiechem. Jeffrey to podsumował równie krótko: różne typy aplikacji wymagają różnych rzeczy. Dyskusja jednak trwała dalej, Butler dodał: “System typów jest weryfikatorem aplikacji” , Jeffrey w odpowiedzi “Prawdziwy świat opiera się na zmianach, kontrakty też nie są stałe, mogą wygasnąć”. Panowie tak się zafiksowali na sprzeczce, że aż Don Box dla żartu wtrącił: “Jestem wielkim fanem stylu TDD, dodajmy nasze testy do dystrybuowanego oprogramowania” w kontekście weryfikacji aplikacji i dostarczenia użytkownikom narzędzia do analizy błędów. 

Dyskusja w temacie Dynamiczne versus Nazwane to nie tylko kwestia błędów i stabilności aplikacji. Panowie omawiali też bezpieczeństwo. Na skrzyżowaniu tych tematów padały też ciekawe sentencje jak “Bezpieczeństwo = nie mogę wykorzystać obiektu, który nie jest w pełni skonstruowany” Burtona.

Jeden ostry temat za drugim, po językach dynamicznych kolej na Native versus Managed. Tutaj znów rozbrojono dokumentnie, śmiałem się z całą salą z kwestii jak “O jakim programowaniu zarządzanym mowa, skoro .NET jedyne co zarządza to pamięć, pointery mogą być lub nie, nazwane typy mogą być lub nie” Burtona Smitha.
Kolejna złota myśl od Herba tym razem: “Możemy zaprojektować język bez pointerów, ale nie możemy bez wyjątków na pointerach”.
 
W dyskusji o pointerach polecam zastanowić się na spokojnie nad paroma kwestiami jak różnica pomiędzy .Net i Native w kwestii bezpieczeństwa pamięci polega tylko na tym, że w C++ musicie wykonać trochę ekstra pracy, to akurat zdanie Herba, które mnie nie dziwi. Herb powinien być znany w środowisku programistów C++. To proste zdanie pociągnęło dyskusję na temat współdzielonej pamięci, cache versus RAM i zdalnych pointerów.

Tutaj rozwalił mnie jak zwykle Butler, który sobie luźno rzucił: “Pomyślcie przez chwilę o adresach URL jako pointerze”. W sumie.. Webservices, REST, ADO.Net Data Services. ASP.Net Routing w MVC. Wiele technologii w Web pozwala nam potraktować magiczny adres URL jako źródło danych a nie efekt końcowy wyrenderowany w przeglądarce. Nawet HTML czy XHTML jak w przykładzie mojego starego konkursu z Wikipedią możną sobie swobodnie ciąć i kleić według uznania.

Rozmowa o C++ i Managed znów nawróciła na programowanie równoległe, kiedy to Butler rzucił kolejne wyzwanie dla przyszłości: jak skutecznie programować na maszynę, która ma 4000 rdzeni na CPU i 300 rdzeni na GPU. Współpraca pomiędzy CPU a GPU już powoli nabiera innego wymiaru wraz z chipami P55. Powyższe hasło faktycznie pobudza wyobraźnię.

Jeffrey do powyższej kwestii dodał, że faktycznie to czego brakuje teraz to takiego kleju pomiędzy komponentami, językami programowania, środowiskami uruchomieniowymi i sprzętem.

Herb odpowiada, że
przejście z sekwencyjnego programowania do równoległego przecież nie jest jakąś tam mistyczną wiedzą.
W porównaniu świata Managed i Native bardzo podobała mi się anegotka z Amazonem versus oprogramowanie do obsługi samolotów. Burton lub Butler (niewyraźnie zapisałem to w notatkach :>) rzekł “Good enough is good enough”. Dał przykład frontendu sklepu internetowego amazon.com, który zawiera wiele błedów, lecz dopóki te błędy to 10% serwisu to nikt sobie tam tym nie zawraca głowy. W przeciwieństwie do takiego software’u do nawigacji w samolocie, gdzie nieodpowiednia tolerancja błędu ma drastyczne w skutkach konsekwencje.

Herb zarzucił temat Garbage Collection w C++, uświadomił mnie nawet (nie wiedziałem), że ten temat był nawet poruszany na forum standaryzacyjnym języka. Zarządzanie pamięcią w C++ to wciąż konsekwencja zamierzchłych czasów w których 1MB RAMu kosztował wiele, a Gigabajty funkcjonowały tylko w wyobraźni wirtualnego limitu linii adresowej w 32bitowym trybie chronionym :>

Kolejna ciekawa kwestia jaka padła to świadomość programistów jak wiele problemów z GC sami sobie generują (sam ten temat poruszyłem na MTS 2009 przy okazji .NET 4.0 Inside/Out). Słynna kwestia u programistów .NET czyli Disposal versus Finalize.

Kolejny duży temat na tym panelu to Modelowanie versus Programowanie.

To temat Dona Boxa, który mocno się ożywił. Don zaprzeczył jakoby nie lubił tekstu i preferował tylko obrazy ponad tekst kodu. Dodał też (co może być pewnym wytłumaczeniem aktualnej wizji Oslo), że Modelowanie zawsze zmierza w kierunku pewnej abstrakcji danych. Wciąż jednak pozwolił sobie na “Text is awesome, text is f… super!” :)

Burton jednak wspomniał o ważnym problemie. Mianowicie to, że automatyczna walidacja modelu to wyzwanie, z którym komputery wciąż nie radzą sobie zbyt dobrze.

Komentarze Butlera już mnie przyzwyczaiły do wesołego cynizmu jaki prezentował cały czas. Jego puenta na temat modelowania znów obudziła całą salę: “Obrazy są pomocne, jeśli wiesz co znaczą, to jest tym bardziej prawdziwe w przypadku diagramów UML”.

Generalnie polecam wam uważnie wsłuchać się w dyskusję dlaczego wciąż zapisujemy źródła programów jako tekst. Obśmiałem się po pachy.

Końcówka to magiczne pytania o czym będziemy w podobnym temacie rozmawiać za 5, 10 lat. Burton rzekł, że wciąż o programowaniu współbieżnym, Herb stwierdził, że optymalizacja znów będzie sexy.

Mam nadzieję, że po tym krótkim sprawozdaniu pobudziłem waszą wyobraźnię na temat formy tego spotkania. Jest ono dostępne do obejrzenia, więc zachęcam was po stokroć, obejrzycie je koniecznie!

Powyższe pogrubienia to z pewnością tylko część co ciekawszych tekstów, które udało mnie się wychwycić, sam na spokojnie mam zamiar wrócić do tego filmiku, aby powyciągać z niego jak najwięcej.