Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00066 006311 12460044 na godz. na dobę w sumie
Wielkie umysły programowania. Jak myślą i pracują twórcy najważniejszych języków - książka
Wielkie umysły programowania. Jak myślą i pracują twórcy najważniejszych języków - książka
Autor: , Liczba stron: 584
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2537-6 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> python - programowanie
Porównaj ceny (książka, ebook, audiobook).

Poznaj z bliska największe autorytety świata informatyki!

Droga od pomysłu do gotowej aplikacji jest długa i kręta. Najprawdopodobniej jednym z najdłuższych jej odcinków jest ten poświęcony na programowanie. Sztab ludzi, wiele języków programowania, technologii i narzędzi. Dzięki świetnej znajomości tych narzędzi powstają coraz nowsze, bardziej niezawodne aplikacje. Ale skąd biorą się języki programowania? Jak powstają i kto za tym stoi?

Na półce księgarni znajdziesz tysiące książek poświęconych językom programowania - i tylko tą jedną, która odpowiada na pytanie, co było na początku. Książka stanowi zbiór wywiadów z twórcami najbardziej znanych i najpopularniejszych języków. W trakcie pasjonującej lektury dowiesz się, co kierowało ludźmi, którzy postanowili stworzyć nowy język programowania, jakie mieli problemy, jak oceniają swoje dzieła z perspektywy czasu i jaką wróżą im przyszłość. Lektura tego tomu to niezwykła podróż przez historię informatyki w niesamowitym wydaniu.

W książce znajdziesz wywiady z autorami takich języków, jak:

Inspirująca i pouczająca podróż przez historię informatyki!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Wielkie umys³y programowania. Jak myœl¹ i pracuj¹ twórcy najwa¿niejszych jêzyków Autorzy: Federico Biancuzzi, Shane Warden T³umaczenie: Rados³aw Meryk ISBN: 978-83-246-2537-6 Tytu³ orygina³u: Masterminds of Programming: Conversations with the Creators of Major Programming Languages Format: 168237, stron: 584 Poznaj z bliska najwiêksze autorytety œwiata informatyki! • Jak powstaj¹ jêzyki programowania? • Jaka jest ich przysz³oœæ? • Jak szybko nauczyæ siê takiego jêzyka? Droga od pomys³u do gotowej aplikacji jest d³uga i krêta. Najprawdopodobniej jednym z najd³u¿szych jej odcinków jest ten poœwiêcony na programowanie. Sztab ludzi, wiele jêzyków programowania, technologii i narzêdzi. Dziêki œwietnej znajomoœci tych narzêdzi powstaj¹ coraz nowsze, bardziej niezawodne aplikacje. Ale sk¹d bior¹ siê jêzyki programowania? Jak powstaj¹ i kto za tym stoi? Na pó³ce ksiêgarni znajdziesz tysi¹ce ksi¹¿ek poœwiêconych jêzykom programowania – i tylko t¹ jedn¹, która odpowiada na pytanie, co by³o na pocz¹tku. Ksi¹¿ka stanowi zbiór wywiadów z twórcami najbardziej znanych i najpopularniejszych jêzyków. W trakcie pasjonuj¹cej lektury dowiesz siê, co kierowa³o ludŸmi, którzy postanowili stworzyæ nowy jêzyk programowania, jakie mieli problemy, jak oceniaj¹ swoje dzie³a z perspektywy czasu i jak¹ wró¿¹ im przysz³oœæ. Lektura tego tomu to niezwyk³a podró¿ przez historiê informatyki w niesamowitym wydaniu. W ksi¹¿ce znajdziesz wywiady z autorami takich jêzyków, jak: • C++ • Python • APL • Forth • BASIC • AWK • Lua • Haskell • ML • SQL • Java • C# • Perl Inspiruj¹ca i pouczaj¹ca podró¿ przez historiê informatyki! S P I S T R E ŀ C I S«OWO WST¤PNE PRZEDMOWA 1 C++ Bjarne Stroustrup Decyzje projektowe UŞywanie j¥zyka Programowanie obiektowe i wspó¬bieŞnoŁý Przysz¬oŁý Edukacja 2 PYTHON Guido van Rossum Pythonowy styl Dobry programista Wiele wersji Pythona Rozwi¡zania praktyczne i doŁwiadczenie 3 APL Adin D. Falkoff Papier i o¬ówek Podstawowe zasady Wspó¬bieŞnoŁý Klasyka 4 FORTH Charles H. Moore J¥zyk Forth a projektowanie j¥zyków Sprz¥t Projektowanie aplikacji 5 BASIC Thomas E. Kurtz Cele j¥zyka BASIC Projektowanie kompilatorów J¥zyk i praktyki programistyczne Projekt j¥zyka Cele pracy 7 9 13 14 19 24 29 33 37 38 47 53 59 65 66 69 76 80 85 86 95 100 109 110 118 122 124 130 3 6 AWK Alfred V. Aho, Peter Weinberger i Brian Kernighan ŝycie algorytmów Projekt j¥zyka Unix i jego kultura Rola dokumentacji Informatyka Hodowla niewielkich j¥zyków Projektowanie nowego j¥zyka Kultura tradycji Technologie transformacji Rzeczy, które zmieni¬y wszechŁwiat Teoria i praktyka Oczekiwanie na prze¬om Programowanie przez przyk¬ad 7 LUA Luiz Henrique de Figueiredo i Roberto Ierusalimschy Si¬a skryptów DoŁwiadczenie Projekt j¥zyka 8 HASKELL Simon Peyton Jones, Paul Hudak, Philip Wadler i John Hughes Zespó¬ j¥zyka funkcyjnego Trajektoria programowania funkcyjnego J¥zyk Haskell Nauczanie programowania (funkcyjnego) Formalizm i ewolucja 9 ML Robin Milner Dowodzenie twierdzeĮ Teoria znaczenia Wykraczaj¡c poza informatyk¥ 10 SQL Don Chamberlin WaŞny dokument J¥zyk Uwagi i ewolucja j¥zyka XQuery i XML 135 136 138 142 147 152 154 160 170 174 179 187 195 201 207 208 212 217 227 228 231 239 247 249 257 258 268 275 283 284 287 292 299 4 S P I S T R E ŀ C I 11 OBJECTIVE-C Brad Cox i Tom Love InŞynieria j¥zyka Objective-C Rozwój j¥zyka Edukacja i szkolenie Zarz¡dzanie projektem i oprogramowanie odziedziczone J¥zyk Objective-C i inne j¥zyki Sk¬adniki, piasek i ceg¬y JakoŁý jako zjawisko ekonomiczne Edukacja 12 JAVA James Gosling Si¬a prostoty Rzecz gustu Wspó¬bieŞnoŁý Projektowanie j¥zyka P¥tla sprz¥Şenia zwrotnego 13 C# Anders Hejlsberg J¥zyk i jego projekt Rozwój j¥zyka C# Przysz¬oŁý informatyki 14 UML Ivar Jacobson, James Rumbaugh i Grady Booch Uczenie si¥ i nauczanie Czynnik ludzki UML Wiedza Przygotuj si¥ na zmiany Korzystanie z UML Warstwy i j¥zyki Troch¥ o wielokrotnym wykorzystywaniu Relacje symetryczne UML Projekt j¥zyka Szkolenie programistów KreatywnoŁý, udoskonalanie i wzorce 303 304 307 312 315 323 329 337 340 345 346 350 354 356 362 365 366 373 378 385 391 392 399 403 408 411 417 423 428 434 438 442 449 451 S P I S T R E ŀ C I 5 15 PERL Larry Wall J¥zyk rewolucji J¥zyk Spo¬ecznoŁý Ewolucja i rewolucja 16 POSTSCRIPT Charles Geschke, John E. Warnock Zaprojektowany po to, Şeby istnieý Badania i edukacja Interfejsy do d¬ugowiecznoŁci Standardowe Şyczenia 17 EIFFEL Bertrand Meyer Owocne popo¬udnie Wielokrotne wykorzystywanie kodu i generycznoŁý Szlifowanie j¥zyków Zarz¡dzanie wzrostem i ewolucj¡ POS«OWIE WSPÓ«TWÓRCY SKOROWIDZ 461 462 467 474 478 485 486 497 502 507 511 512 521 526 534 541 543 561 6 S P I S T R E ŀ C I S§owo wst£pne PROJEKTOWANIE J¢ZYKÓW PROGRAMOWANIA TO WSPANIA¦Y TEMAT. Istnieje bardzo wielu programistów, którzy uwaŗajŸ, ŗe potrafiŸ zaprojektowaó lepszy j£zyk programowania od tego, którego aktualnie uŗywajŸ. Istnieje równieŗ bardzo wielu naukowców, którzy wierzŸ, ŗe potrafiŸ zaprojektowaó lepszy j£zyk programowania od jakiegokolwiek innego j£zyka b£dŸcego w uŗyciu. Ich osŸdy sŸ cz£sto uzasadnione, ale tylko kilka takich projektów opuĺci§o dolnŸ szuflad£ projektanta. O takich j£zykach Czytelnik nie znajdzie informacji w tej ksiŸŗce. Projektowanie j£zyków programowania to powaŗny biznes. Niewielkie b§£dy w projekcie j£zyka mogŸ byó przyczynŸ duŗych b§£dów w ostatecznym programie, a nawet niewielkie b§£dy w programach mogŸ mieó powaŗne konsekwencje i wiŸzaó si£ z bardzo duŗymi kosztami. Wraŗliwe punkty powszechnie wykorzystywanego oprogramowania cz£sto umoŗliwia§y ataki za poĺrednictwem z§oĺliwego oprogramowania. Czasami powodowa§o to w gospodarce ĺwiatowej straty rz£du wielu miliardów dolarów. Bezpieczeħstwo i zabezpieczenia j£zyków programowania to motyw, który bardzo cz£sto pojawia si£ w niniejszej ksiŸŗce. Projektowanie j£zyków programowania to nieprzewidywalna przygoda. J£zyki projektowane pod kŸtem tworzenia uniwersalnych aplikacji, nawet jeĺli sŸ wspierane i sponsorowane przez pot£ŗne organizacje, czasami koħczŸ na rynku niszowym. 7 Z drugiej strony j£zyki projektowane z myĺlŸ o ograniczonych lub lokalnych zastosowaniach czasami zyskujŸ licznŸ klientel£ — takŗe w ĺrodowiskach i aplikacjach, o których ich projektanci nigdy nawet nie marzyli. Niniejsza ksiŸŗka koncentruje si£ na j£zykach tego drugiego typu. J£zyki, które odnios§y sukces, majŸ jednŸ istotnŸ cech£: kaŗdy z nich powsta§ w g§owie jednego cz§owieka lub jest efektem pracy ma§ej grupy podobnie myĺlŸcych entuzjastów. Projektanci tych j£zyków to mistrzowie programowania. MajŸ doĺwiadczenie, wizj£, energi£, wytrwa§oĺó oraz prawdziwy geniusz. Cechy te pozwalajŸ im przeprowadzió j£zyk od wst£pnej implementacji, poprzez ewolucj£ wynikajŸcŸ z doĺwiadczeħ, aŗ do standaryzacji b£dŸcej efektem wykorzystywania (standardy de facto) oraz przeprowadzanej oficjalnie (przez komitety standaryzacyjne). W niniejszej ksiŸŗce Czytelnik spotka si£ z wieloma geniuszami. Z kaŗdym z nich zosta§ przeprowadzony obszerny wywiad na temat historii j£zyka oraz czynników, które wp§yn£§y na jego sukces. Wywiady te potwierdzajŸ istotnŸ rol£ dobrych decyzji po§Ÿczonych ze szcz£ĺciem. Publikacja s§ów wypowiadanych w wywiadzie pozwoli Czytelnikowi ocenió osobowoĺó oraz motywacje projektantów. Jest to temat równie fascynujŸcy jak sam projekt j£zyka. — Sir Tony Hoare Sir Tony Hoare, zdobywca nagrody Turinga stowarzyszenia ACM oraz nagrody Kyoto Award, od 50 lat jest liderem badaĨ nad algorytmami komputerowymi oraz j£zykami programowania. W swoim pierwszym akademickim artykule, który zosta§ opublikowany w 1969 roku, opisa§ ide£ dowodzenia poprawnoĻci programów i zasugerowa§, aby celem projektu j£zyka programowania by§o u§atwienie pisania poprawnych programów. Jest zachwycony tym, Śe idea ta zosta§a stopniowo zaakceptowana przez projektantów j£zyków programowania. 8 S « O W O W S T ¤ P N E Przedmowa PISANIE OPROGRAMOWANIA NIE NALEŜY DO ¦ATWYCH ZAJ¢÷. A JUŜ NA PEWNO NIE JEST ¦ATWE PISANIE PROGRAMÓW, KTÓRE SPE¦NIAJž WYMAGANIA TESTÓW, CZASU oraz róŗnych ĺrodowisk. W ciŸgu ostatnich pi£ciu dekad w branŗy inŗynierii oprogramowania nie tylko czyniono wysi§ki, aby pisanie oprogramowania stawa§o si£ coraz §atwiejsze, ale takŗe projektowano j£zyki pod tym kŸtem. Dlaczego jednak pisanie oprogramowania w ogóle jest trudne? W wi£kszoĺci ksiŸŗek i artyku§ów zajmujŸcych si£ tym problemem mówi si£ o architekturze, wymaganiach oraz podobnych zagadnieniach zwiŸzanych z oprogramowaniem. A co, jeĺli ca§a trudnoĺó polega na pisaniu? MówiŸc inaczej, zastanówmy si£, jakby wyglŸda§ problem, gdyby programiĺci postrzegali swojŸ prac£ bardziej w kategoriach komunikacji — j£zyka — a mniej w kategoriach inŗynierii. Dzieci uczŸ si£ mówió przez pierwsze lata ŗycia, natomiast czytania i pisania zaczynajŸ si£ uczyó dopiero wtedy, gdy skoħczŸ pi£ó, szeĺó lat. Nie znam ŗadnego wielkiego autora, który nauczy§ si£ czytaó i pisaó jako doros§y. Czy znacie jakiegoĺ programist£, który nauczy§ si£ programowania w zaawansowanym wieku? Jeĺli dzieci znacznie §atwiej uczŸ si£ obcych j£zyków niŗ doroĺli, to co powiedzieó o uczeniu si£ programowania — czynnoĺci wymagajŸcej poznawania nowego j£zyka? 9 Wyobraŕmy sobie, ŗe uczymy si£ obcego j£zyka i nie znamy nazwy jakiegoĺ przedmiotu. Potrafimy opisaó go s§owami, które znamy, z nadziejŸ, ŗe nasz rozmówca zrozumie, co mamy na myĺli. Czy to nie jest to samo, co robimy codziennie, piszŸc programy? Opisujemy obiekt, który mamy na myĺli, za pomocŸ j£zyka programowania w nadziei, ŗe nasz opis b£dzie wystarczajŸco czytelny dla kompilatora bŸdŕ interpretera. Jeĺli coĺ nie zadzia§a, jeszcze raz przywo§ujemy obraz obiektu i próbujemy zrozumieó, co pomin£liĺmy lub co opisaliĺmy niewystarczajŸco dok§adnie. Ĺwiadomy tych pytaħ postanowi§em przeprowadzió szereg badaħ na temat tego, po co tworzy si£ j£zyki programowania, w jaki sposób technicznie si£ je opracowuje, jak si£ ich naucza, jak sŸ przyswajane oraz jak rozwijajŸ si£ z biegiem lat. Shane i ja mieliĺmy honor porozmawiania z 27 wielkimi projektantami j£zyków. Osoby te przeprowadzi§y nas przez swojŸ prac£. Staraliĺmy si£ zebraó ich wiedz£ i doĺwiadczenie, a nast£pnie przedstawió je Czytelnikowi. W ksiŸŗce Masterminds of Programming Czytelnik zapozna si£ z pewnymi schematami myĺlenia i czynnoĺciami wymaganymi do stworzenia sprawnego j£zyka programowania. Dowie si£, co wp§ywa na to, ŗe j£zyk staje si£ popularny, oraz zapozna ze sposobami rozwiŸzywania bieŗŸcych problemów, z jakimi spotykajŸ si£ programiĺci uŗywajŸcy tego j£zyka. Jeĺli zatem Czytelnik chce si£ dowiedzieó, w jaki sposób projektowaó j£zyki programowania zdolne do osiŸgni£cia sukcesu, ta ksiŸŗka z pewnoĺciŸ b£dzie mu pomocna. Osoby poszukujŸce inspiracji dotyczŸcych oprogramowania i j£zyków programowania b£dŸ potrzebowa§y kolorowego markera do zaznaczania interesujŸcych fragmentów. Obiecuj£, ŗe na kartach niniejszej ksiŸŗki znajdŸ wiele informacji godnych zaznaczenia. — Federico Biancuzzi Organizacja materia§u Rozdzia§y w niniejszej ksiŸŗce uporzŸdkowano w taki sposób, aby przekazywaó Czytelnikom róŗne poglŸdy i prowokowaó. Polecamy smakowaó poszczególne wywiady i cz£sto do nich powracaó. Rozdzia§ 1., „C++”, wywiad z Bjarne’em Stroustrupem. Rozdzia§ 2., „Python”, wywiad z Guidem van Rossumem. Rozdzia§ 3., „APL”, wywiad z Adinem D. Falkoffem. Rozdzia§ 4., „Forth”, wywiad z Charlesem H. Moore’em. Rozdzia§ 5., „BASIC”, wywiad z Thomasem E. Kurtzem. Rozdzia§ 6., „AWK”, wywiad z Alfredem Aho, Peterem Weinbergerem i Brianem Kernighanem. 10 P R Z E D M O W A Rozdzia§ 7., „Lua”, wywiad z Luizem Henrique de Figueiredo i Robertem Ierusalimschym. Rozdzia§ 8., „Haskell”, wywiad z Simonem Peytonem Jonesem, Paulem Hudakiem, Philipem Wadlerem i Johnem Hughesem. Rozdzia§ 9., „ML”, wywiad z Robinem Milnerem. Rozdzia§ 10., „SQL”, wywiad z Donem Chamberlinem. Rozdzia§ 11., „Objective-C”, wywiad z Tomem Love’em i Bradem Coksem. Rozdzia§ 12., „Java”, wywiad z Jamesem Goslingiem. Rozdzia§ 13., „C#”, wywiad z Andersem Hejlsbergiem. Rozdzia§ 14., „UML”, wywiad z Ivarem Jacobsonem, Jamesem Rumbaughem i Gradym Boochem. Rozdzia§ 15., „Perl”, wywiad z Larrym Wallem. Rozdzia§ 16., „PostScript”, wywiad z Charlesem Geschkem i Johnem Warnockiem. Rozdzia§ 17., „Eiffel”, wywiad z Bertrandem Meyerem. W dodatku „Wspó§twórcy” zamieszczono biografie wszystkich rozmówców. Konwencje stosowane w ksiŸŝce W niniejszej ksiŸŗce zastosowano nast£pujŸce konwencje typograficzne: Kursywa Oznacza nowe poj£cia, adresy URL, nazwy plików i narz£dzi. Czcionka o stađej szerokoħci Oznacza zawartoĺó plików komputerowych oraz — ogólnie rzecz biorŸc — wszystkiego, co moŗna znaleŕó w programach. P R Z E D M O W A 11 12 P R Z E D M O W A R O Z D Z I A « P I E R W S Z Y C++ C++ zajmuje interesuj¡ce miejsce wŁród j¥zyków: jest zbudowany na bazie j¥zyka C, implementuje mechanizmy obiektowe pochodz¡ce z j¥zyka Simula, jest ustandaryzowany przez ISO oraz zaprojektowany wed¬ug dwóch idei: „nie p¬acisz za to, czego nie uŞywasz” oraz „typy definiowane przez uŞytkownika powinny byý obs¬ugiwane na równi z wbudowanymi”. ChociaŞ j¥zyk ten zosta¬ spopularyzowany w latach osiemdziesi¡tych i dziewi¥ýdziesi¡tych jako narz¥dzie programowania obiektowego uŞywane do tworzenia programów z graficznym interfejsem uŞytkownika (GUI), to jedn¡ z jego najwi¥kszych zas¬ug na polu rozwoju oprogramowania s¡ techniki programowania generycznego udost¥pnione w bibliotece STL (ang. Standard Template Library). Próbowano zast¡piý j¥zyk C++ nowszymi j¥zykami, takimi jak Java czy C#, tymczasem do kolejnej wersji standardu C++ dodano nowe, d¬ugo oczekiwane w¬asnoŁci. Twórc¡ j¥zyka C++ i jednym z jego gor¡cych or¥downików jest Bjarne Stroustrup. 13 Decyzje projektowe Dlaczego zdecydowa¬ si¥ pan rozszerzyý istniej¡cy j¥zyk, zamiast stworzyý nowy? Bjarne Stroustrup: Kiedy zaczyna§em — w 1979 roku — moim celem by§a pomoc programistom w budowaniu systemów. W dalszym ciŸgu przyĺwieca mi taki cel. Aby j£zyk programowania stanowi§ prawdziwŸ pomoc w rozwiŸzywaniu problemów, a nie by§ tylko akademickim ówiczeniem, musi byó kompletny w zakresie narz£dzi do tworzenia aplikacji. A zatem potrzebny jest prosty j£zyk do rozwiŸzywania problemów. Problemy, które stara§em si£ rozwiŸzaó, dotyczy§y projektowania systemów operacyjnych, obs§ugi sieci i symulacji. Ja i moi koledzy potrzebowaliĺmy j£zyka, za pomocŸ którego moŗna by prezentowaó organizacj£ programu, tak jak to moŗna robió w j£zyku Simula (potrzebne nam zatem by§y techniki obiektowe). Jednoczeĺnie potrzebowaliĺmy takiego j£zyka, za pomocŸ którego moŗna pisaó wydajny kod niskopoziomowy — tak jak w j£zyku C. W 1979 roku nie by§o j£zyka, który posiada§by obie te cechy, a przynajmniej ja takiego nie zna§em. W§aĺciwie nie chcia§em projektowaó nowego j£zyka programowania. Chcia§em tylko pomóc w rozwiŸzaniu kilku problemów. Bazowanie na istniejŸcym j£zyku programowania ma bowiem sens. Z j£zyka bazowego bierzemy podstawowŸ struktur£ sk§adni i semantyki, wykorzystujemy z niego uŗyteczne biblioteki i stajemy si£ cz£ĺciŸ kultury. Gdybym nie wykorzysta§ j£zyka C, opar§bym j£zyk C++ na jakimĺ innym j£zyku. Dlaczego C? Mia§em Dennisa Ritchiego, Briana Kernighana i innych wielkich twórców Uniksa w odleg§oĺci pi£tra lub pokoju w Computer Science Research Center — Bell Labs, a zatem pytanie to moŗe wydawaó si£ bezzasadne. Ja jednak potraktowa§em je zupe§nie serio. W szczególnoĺci system typów j£zyka C by§ nieformalny i niezbyt dobrze przestrzegany (jak powiedzia§ Dennis Ritchie: „C jest j£zykiem o ĺcis§ej typizacji (ang. strongly typed) i s§abo kontrolowanych typach”). Cecha „s§abo kontrolowane” mnie martwi§a, zresztŸ do dziĺ sprawia ona programistom j£zyka C++ wiele problemów. J£zyk C nie by§ wtedy powszechnie uŗywany, tak jak to si£ dzieje dziĺ. Oparcie j£zyka C++ na j£zyku C by§o wyrazem wiary w model przetwarzania b£dŸcy podstawŸ j£zyka C (cecha „ĺcis§a typizacja”) oraz wyrazem zaufania do moich kolegów. Wyboru dokona§em na podstawie wiedzy na temat wi£kszoĺci j£zyków wyŗszego poziomu wykorzystywanych w tamtych czasach do tworzenia systemów (zna§em je zarówno jako uŗytkownik, jak i praktykujŸcy programista). Warto pami£taó, ŗe by§ to czas, w którym wi£kszoĺó prac „blisko sprz£tu” oraz wymagajŸcych dobrej wydajnoĺci by§o wykonywanych w asemblerze. Powstanie systemu Unix stanowi§o powaŗny prze§om pod wieloma wzgl£dami — jednym z nich by§o uŗycie j£zyka C nawet do najbardziej wymagajŸcych zadaħ programowania systemowego. W zwiŸzku z tym wybra§em wykorzystywany w j£zyku C prosty model maszyny, który uzna§em za bardziej wartoĺciowŸ cech£ od lepszej kontroli typów wyst£pujŸcej w innych j£zykach. Tym, czego naprawd£ potrzebowa§em jako ramy (ang. framework) 14 R O Z D Z I A « P I E R W S Z Y do tworzenia programów, by§y klasy dost£pne w Simuli. Dlatego przenios§em je na model pami£ci i przetwarzania w§aĺciwy j£zykowi C. W efekcie powsta§o niezwykle ekspresywne i elastyczne narz£dzie, które pod wzgl£dem szybkoĺci dzia§ania mog§o rywalizowaó z asemblerem i nie wymaga§o stosowania rozbudowanego ĺrodowiska wykonawczego. Dlaczego zdecydowa¬ si¥ pan na wspieranie wielu paradygmatów? Bjarne: Poniewaŗ kombinacja stylów programowania cz£sto prowadzi do stworzenia lepszego kodu, przy czym „lepszy” oznacza kod, który w bardziej bezpoĺredni sposób odzwierciedla projekt, dzia§a szybciej, jest §atwiejszy w zarzŸdzaniu itp. DŸŗŸc do tworzenia lepszego kodu, ludzie albo próbujŸ zdefiniowaó swój ulubiony styl programowania zawierajŸcy wszystkie uŗyteczne konstrukcje (na przyk§ad „programowanie generyczne jest po prostu formŸ programowania obiektowego”), albo wy§ŸczajŸ pewne obszary aplikacji (na przyk§ad zak§adajŸ, ŗe „kaŗdy ma maszyn£ z zegarem 1GHz i pami£ciŸ 1 GB”). J¥zyk Java koncentruje si¥ wy¬¡cznie na programowaniu obiektowym. Czy to powoduje, Şe kod Javy jest w pewnych przypadkach — tam, gdzie w j¥zyku C++ moŞna skorzystaý z programowania generycznego — bardziej z¬oŞony? Bjarne: No cóŗ, projektanci Javy — a moŗe raczej osoby zajmujŸce si£ marketingiem — promowali programowanie obiektowe do granic absurdu. Kiedy Java pojawi§a si£ po raz pierwszy, a jej twórcy podkreĺlali czystoĺó i prostot£ tego kodu, przewidzia§em, ŗe w przypadku sukcesu Java znacznie si£ rozroĺnie i wzroĺnie jej z§oŗonoĺó. Tak teŗ si£ sta§o. I tak wykorzystanie rzutowania do konwersji z typu Object podczas pobierania wartoĺci z kontenera (na przyk§ad (Apple)c.get(i)) jest absurdalnŸ konsekwencjŸ braku moŗliwoĺci wyspecyfikowania typu, jaki powinny mieó obiekty w kontenerze. To sposób rozwlek§y i nieefektywny. Teraz Java ma typy generyczne, zatem jest tylko nieco wolniejsza. Innymi przyk§adami zwi£kszonej z§oŗonoĺci j£zyka (w celu pomocy programistom) sŸ typy wyliczeniowe (enumeracje), odbicia oraz klasy wewn£trzne. Faktem jest, ŗe z§oŗonoĺó musi si£ gdzieĺ pojawió. Jeĺli nie ma jej w definicji j£zyka, to b£dzie w niezliczonych aplikacjach i bibliotekach. Na podobnej zasadzie obsesja, by w Javie kaŗdy algorytm (operacj£) implementowaó w postaci klasy, prowadzi do absurdów — na przyk§ad klas bez danych, które sk§adajŸ si£ w ca§oĺci z funkcji statycznych. IstniejŸ powody, dla których w matematyce stosuje si£ zapisy f(x) i f(x,y) zamiast x.f(), x.f(y) czy teŗ (x,y).f() — zapis (x,y).f() jest próbŸ wyraŗenia idei „prawdziwie obiektowego sposobu” przedstawiania dwóch argumentów oraz unikni£cia asymetrii w§aĺciwej dla zapisu x.f(y). Dzi£ki po§Ÿczeniu abstrakcji danych i technik programowania generycznego j£zyk C++ rozwiŸzuje wiele problemów dotyczŸcych logiki i notacji wynikajŸcych z podejĺcia obiektowego. Klasycznym przyk§adem jest zapis vector T , w którym T moŗe byó C + + 15 dowolnym typem moŗliwym do kopiowania — w§Ÿcznie z typami wbudowanymi, wskaŕnikami na hierarchie obiektowe oraz typami definiowanymi przez uŗytkowników — na przyk§ad ciŸgami znaków i liczbami zespolonymi. Wszystko to osiŸgni£to bez dodatkowych kosztów w fazie dzia§ania, nak§adania ograniczeħ na rozmieszczenie danych w pami£ci czy teŗ stosowania specjalnych regu§ dotyczŸcych standardowych komponentów bibliotecznych. Innym przyk§adem, który nie pasuje do klasycznego modelu pojedynczej dyspozycji (ang. single dispatch) charakterystycznego dla programowania obiektowego, jest operacja wymagajŸca dost£pu do dwóch klas, na przyk§ad operator*(Macierz,Wektor). Operacja ta naturalnie nie moŗe byó metodŸ ŗadnej z klas. Jedn¡ z podstawowych róŞnic pomi¥dzy j¥zykami C++ i Jav¡ jest sposób implementacji wskaŜników. W pewnym sensie moŞna powiedzieý, Şe j¥zyk Java nie posiada prawdziwych wskaŜników. Jakie róŞnice wyst¥puj¡ pomi¥dzy tymi dwoma podejŁciami? Bjarne: Cóŗ, w j£zyku Java oczywiĺcie sŸ wskaŕniki. W rzeczywistoĺci niemal wszystko w Javie to niejawne wskaŕniki. Tyle ŗe nazwano je referencjami. Niejawnoĺó wskaŕników ma zarówno zalety, jak i wady. Podobnie istniejŸ zarówno zalety, jak i wady rzeczywistego wyst£powania lokalnych obiektów (tak jak w C++). Podejĺcie zastosowane w C++, polegajŸce na wspieraniu zmiennych lokalnych alokowanych na stosie oraz rzeczywistych zmiennych cz§onkowskich dowolnego typu, gwarantuje wygodnŸ jednolitŸ semantyk£, kompaktowy uk§ad i minimalne koszty dost£pu oraz stanowi podstaw£ dla obs§ugi ogólnego zarzŸdzania zasobami w j£zyku C++. To jest bardzo waŗne, a wszechobecne i niejawne stosowanie wskaŕników w Javie (zwanych tam referencjami) zamyka drzwi do wszystkich tych mechanizmów. Przeanalizujmy sprawy zwiŸzane z rozmieszczeniem danych w pami£ci. W j£zyku C++ konstrukcja vector complex (10) jest reprezentowana jako uchwyt do tablicy 10 liczb zespolonych w wolnej pami£ci. W sumie zajmuje ona 25 s§ów: 3 s§owa na wektor plus 20 s§ów na liczby zespolone oraz dodatkowo 2 s§owa na nag§ówek tablicy w wolnej pami£ci (stercie). Odpowiednik w Javie (dla zdefiniowanego przez uŗytkownika kontenera zawierajŸcego obiekty typów niestandardowych) zajŸ§by 56 s§ów: 1 na referencj£ do kontenera plus 3 na kontener plus 10 na referencje do obiektów plus 20 na obiekty plus 24 na przechowywane w wolnej pami£ci nag§ówki 12 niezaleŗnie alokowanych obiektów. Oczywiĺcie te liczby sŸ przybliŗone, poniewaŗ koszty obs§ugi wolnej pami£ci (sterty) sŸ zdefiniowane w implementacji obu j£zyków. Konkluzja jest jednak oczywista: przez wszechobecne i niejawne stosowanie referencji w Javie uproszczono model programowania i implementacj£ mechanizmu odĺmiecania (ang. garbage collector), ale jednoczeĺnie dramatycznie zwi£kszono koszty pami£ciowe, podwyŗszono koszty dost£pu do pami£ci (z powodu wi£kszej liczby poĺrednich operacji dost£pu) oraz proporcjonalnie zwi£kszono koszty alokacji. 16 R O Z D Z I A « P I E R W S Z Y Tym, czego Java nie ma — i dobrze dla Javy — jest moŗliwoĺó nieprawid§owego uŗywania wskaŕników w dzia§aniach arytmetycznych na wskaŕnikach. Jednak dobrze napisanego kodu w C++ ten problem i tak nie dotyka: zamiast wykonywaó dzia§ania na wskaŕnikach, programiĺci uŗywajŸ bardziej wysokopoziomowych abstrakcji, takich jak strumienie wejĺcia-wyjĺcia, kontenery, lub stosujŸ zaawansowane algorytmy. W zasadzie wszystkie tablice — to samo dotyczy wi£kszoĺci wskaŕników — pozostajŸ ukryte g§£boko w implementacjach, czyli w miejscach, których wi£kszoĺó programistów nie musi widzieó. Niestety, istnieje równieŗ wiele ŕle napisanego i niepotrzebnie niskopoziomowego kodu w j£zyku C++. Jest jednak istotne miejsce, w którym wskaŕniki i dzia§ania na nich sŸ wielkŸ zaletŸ: bezpoĺrednie i wydajne prezentowanie struktur danych. Referencje Javy nie dajŸ takich samych moŗliwoĺci — na przyk§ad w Javie nie moŗna przedstawió operacji wymiany. Inny przyk§ad to uŗycie wskaŕników do niskopoziomowego bezpoĺredniego dost£pu do pami£ci (fizycznej). W kaŗdym systemie trzeba to robió w jakimĺ j£zyku i cz£sto tym j£zykiem jest C++. Z wyst£powaniem wskaŕników (i tablic w stylu j£zyka C) wiŸŗe si£ oczywiĺcie ryzyko niew§aĺciwego wykorzystania: przepe§nienia bufora, uŗycia wskaŕników w odniesieniu do usuni£tej pami£ci, wystŸpienia wskaŕników niezainicjowanych itp. Jednak w dobrze napisanym kodzie C++ nie stanowi to wielkiego problemu. Problem ten po prostu nie wyst£puje w przypadku wskaŕników i tablic wykorzystywanych wewnŸtrz abstrakcji (na przyk§ad vector, string, map itp.). ZarzŸdzanie zasobami z wykorzystaniem zasi£gów (ang. scope) za§atwia wi£kszoĺó potrzeb. Pozosta§e problemy moŗna rozwiŸzaó dzi£ki zastosowaniu inteligentnych wskaŕników i specjalizowanych uchwytów. Programistom z doĺwiadczeniem g§ównie w j£zyku C lub C++ starego stylu trudno b£dzie w to uwierzyó, ale zarzŸdzanie zasobami bazujŸce na zasi£gach to niezwykle mocne narz£dzie. Zasi£gi definiowane przez uŗytkownika z odpowiednimi operacjami pozwalajŸ rozwiŸzywaó klasyczne problemy za pomocŸ mniejszej iloĺci kodu w porównaniu ze starymi niebezpiecznymi sposobami. Oto na przyk§ad najprostsza postaó klasycznego problemu przepe§nienia bufora stwarzajŸcego zagroŗenie dla bezpieczeħstwa: char buf[MAX_BUF]; gets(buf); // Oops! Wystarczy skorzystaó ze standardowej biblioteki string, a problem zniknie: string s; cin s; // odczyt znaków oddzielanych spacjami SŸ to oczywiĺcie trywialne przyk§ady, ale odpowiednie ciŸgi znaków i kontenery moŗna zbudowaó w taki sposób, by spe§nia§y w§aĺciwie wszystkie potrzeby. Dobrym miejscem do rozpocz£cia poszukiwaħ jest standardowa biblioteka. C + + 17 Co pan rozumie pod poj¥ciami „semantyka wartoŁci” oraz „ogólne zarz¡dzanie zasobami”? Bjarne: „Semantyka wartoĺci” to termin powszechnie uŗywany w odniesieniu do klas, w których obiekty majŸ w§aĺciwoĺó dajŸcŸ po skopiowaniu dwie niezaleŗne kopie obiektów (z tŸ samŸ wartoĺciŸ). Na przyk§ad: X x1 = a; X x2 = x1; // Teraz x1 == x2 x1 = b; // Zmienia si£ x1, ale nie x2 // teraz x1! = x2 (pod warunkiem Śe X(a)! = X(b)) Taka cecha dotyczy oczywiĺcie zwyk§ych typów numerycznych, jak liczby int, double, liczby zespolone oraz matematyczne abstrakcje, na przyk§ad wektory. Jest to najbardziej uŗyteczna w§asnoĺó. C++ obs§uguje jŸ dla typów wbudowanych oraz dla dowolnych typów definiowanych przez uŗytkownika, dla których chcemy jŸ mieó. Pod tym wzgl£dem j£zyk C++ róŗni si£ od Javy — tu typy wbudowane, takie jak char i int, posiadajŸ t£ w§asnoĺó, ale typy definiowane przez uŗytkowników jej nie majŸ i nie mogŸ mieó. Tak jak w j£zyku Simula, wszystkie typy definiowane przez uŗytkownika w Javie majŸ semantyk£ referencji. W C++ programista moŗe zastosowaó dowolnŸ spoĺród tych dwóch semantyk, zgodnie z wymaganiami typu. J£zyk C# naĺladuje j£zyk C++ (choó nie do koħca) w obs§udze typów uŗytkownika z semantykŸ wartoĺci. Termin „ogólne zarzŸdzanie zasobami” odnosi si£ do popularnej techniki posiadania zasobu przez obiekt (na przyk§ad uchwytu do pliku lub blokady). Jeĺli ten obiekt jest zmiennŸ zdefiniowanŸ w pewnym zasi£gu, to czas ŗycia zmiennej wprowadza maksymalny limit czasu, przez jaki utrzymywany jest zasób. Zazwyczaj konstruktor alokuje zasób, a destruktor go zwalnia. Takie dzia§anie, cz£sto okreĺlane terminem RAII (od ang. Resource Acquisition Is Initialization — dos§. zdobycie zasobu to inicjalizacja), doskonale si£ integruje z obs§ugŸ b§£dów z wykorzystaniem wyjŸtków. Oczywiĺcie nie kaŗdy zasób moŗna obs§uŗyó w ten sposób, ale w wielu przypadkach jest to moŗliwe. Wtedy zarzŸdzanie zasobami staje si£ niejawne i wydajne. Wydaje si¥, Şe zasada „blisko sprz¥tu” by¬a wiod¡c¡ regu¬¡ podczas projektowania j¥zyka C++. Czy moŞna powiedzieý, Şe j¥zyk C++ zosta¬ zaprojektowany w uk¬adzie dó¬-góra, podczas gdy wiele j¥zyków programowania jest projektowanych w uk¬adzie góra-dó¬, w tym sensie, Şe dostarczaj¡ one abstrakcyjnie racjonalnych konstrukcji i zmuszaj¡ kompilator do tego, by dopasowywa¬ te konstrukcje do dost¥pnego Łrodowiska przetwarzania? Bjarne: Uwaŗam, ŗe okreĺlenia góra-dó§ i dó§-góra to z§e sposoby charakteryzowania tych decyzji projektowych. W kontekĺcie j£zyka C++ i innych j£zyków „blisko sprz£tu” oznacza, ŗe jest przyj£ty model obliczeħ danego komputera — sekwencje obiektów w pami£ci oraz operacje definiowane na obiektach o sta§ym rozmiarze zamiast jakiejĺ 18 R O Z D Z I A « P I E R W S Z Y abstrakcji matematycznej. Tak jest zarówno w przypadku j£zyka C++, jak i Javy, ale w odniesieniu do j£zyków funkcyjnych jest inaczej. C++ róŗni si£ od Javy tym, ŗe pod spodem jest maszyna fizyczna, a nie maszyna abstrakcyjna. Prawdziwy problem polega na tym, jak przejĺó od ludzkiego sposobu postrzegania problemów i rozwiŸzaħ do ograniczonego ĺwiata maszyny. Moŗna zignorowaó ludzkie rozterki i stworzyó kod maszynowy (lub gloryfikowany kod maszynowy w postaci z§ego kodu w j£zyku C). Moŗna teŗ zignorowaó rozterki maszyny i uzyskaó pi£kne abstrakcje, które pozwalajŸ na wykonywanie dowolnych operacji olbrzymim kosztem i (lub) bez ograniczeħ zdroworozsŸdkowych. J£zyk C++ to próba uzyskania bezpoĺredniego dost£pu do sprz£tu (na przyk§ad za poĺrednictwem wskaŕników i tablic) tam, gdzie jest taka potrzeba, z jednoczesnym dostarczeniem rozbudowanych mechanizmów abstrakcyjnych pozwalajŸcych na wyraŗanie idei wysokopoziomowych (na przyk§ad hierarchii klas i szablonów). W zwiŸzku z takimi za§oŗeniami podczas tworzenia j£zyka C++ i jego bibliotek zwracano bacznŸ uwag£ na wydajnoĺó kodu wynikowego i zarzŸdzanie pami£ciŸ. Te aspekty przenikajŸ zarówno podstawowe mechanizmy j£zyka, jak i mechanizmy abstrakcyjne w sposób wyróŗniajŸcy j£zyk C++ spoĺród innych j£zyków. Uŝywanie j£zyka W jaki sposób debuguje pan swój kod? Czy ma pan jakieŁ wskazówki dla programistów C++? Bjarne: Przez wnikliwŸ analiz£. Studiuj£ program i oglŸdam go mniej lub bardziej systematycznie tak d§ugo, aŗ mam wystarczajŸcŸ wiedz£ do tego, by w inteligentny sposób odgadnŸó miejsce wystŸpienia b§£du. Testowanie to zupe§nie inna sprawa. Podobnie jak odpowiedni projekt zmierzajŸcy do zminimalizowania liczby b§£dów. Bardzo nie lubi£ debugowania i robi£ wszystko, by go uniknŸó. Jeĺli jestem programistŸ fragmentu oprogramowania, buduj£ go na bazie interfejsów i niezmienników, dlatego trudno mi uzyskaó kod z duŗŸ liczbŸ b§£dów, który nie daje si£ skompilowaó i uruchomió. Nast£pnie bardzo si£ staram, aby kod moŗna by§o przetestowaó. Testowanie jest systematycznym poszukiwaniem b§£dów. Trudno testowaó w sposób systematyczny systemy, które majŸ nieprawid§owŸ struktur£, dlatego jeszcze raz zalecam dba§oĺó o czytelnŸ struktur£ kodu. Testowanie moŗna zautomatyzowaó i wykonywaó wielokrotnie, podczas gdy w przypadku debugowania nie da si£ tego uzyskaó. Wykorzystanie stada go§£bi, które losowo siadajŸ na ekranie, po to, by zobaczyó, czy uda im si£ z§amaó aplikacj£ okienkowŸ, nie jest sposobem na zapewnienie wysokiej jakoĺci systemów. Moja rada? Trudno dawaó uniwersalne rady, poniewaŗ najlepsze techniki cz£sto zaleŗŸ od tego, co jest wykonalne w danym systemie oraz ĺrodowisku projektowym. Jeĺli jednak mog£ coĺ radzió: naleŗy zidentyfikowaó kluczowe interfejsy, które moŗna C + + 19 systematycznie testowaó, a nast£pnie napisaó skrypty testowe, które to robiŸ. Naleŗy stosowaó automatyzacj£ tam, gdzie to moŗliwe, i cz£sto uruchamiaó takie automatyczne testy. Warto teŗ cz£sto wykonywaó testy regresji. Naleŗy dŸŗyó to tego, by kaŗdy punkt wejĺcia do systemu i wyjĺcia z systemu by§ systematycznie przetestowany. System powinien byó z§oŗony z komponentów o wysokiej jakoĺci: monolityczne programy sŸ niepotrzebnie skomplikowane, przez co sŸ trudne do zrozumienia i przetestowania. Na jakim poziomie konieczna jest poprawa bezpieczeĮstwa oprogramowania? Bjarne: Po pierwsze, bezpieczeħstwo jest problemem systemowym. Ŗadne lokalne lub cz£ĺciowe rozwiŸzanie nie zapewni sukcesu. Naleŗy pami£taó, ŗe nawet gdyby ca§y kod by§ perfekcyjny, to i tak uda§oby si£ uzyskaó dost£p do zapisanych sekretów komuĺ, kto ukrad§by nasz komputer lub noĺnik z kopiŸ zapasowŸ. Po drugie, bezpieczeħstwo jest kompromisem pomi£dzy kosztami a korzyĺciami: doskona§e bezpieczeħstwo prawdopodobnie jest poza zasi£giem wi£kszoĺci z nas. Moŗna jednak zabezpieczyó system na tyle mocno, aby ŕli ch§opcy woleli poĺwi£ció swój czas na próby w§amania do innego systemu. Sam dŸŗ£ do tego, by nie przechowywaó waŗnych sekretów online, a problemy dotyczŸce powaŗnych zabezpieczeħ pozostawiam ekspertom. Co jednak z j£zykami programowania i technikami programowania? Istnieje niebezpieczna tendencja do zak§adania, ŗe kaŗda linijka kodu musi byó bezpieczna (cokolwiek by to oznacza§o). Niektórzy przyjmujŸ nawet, ŗe w ramach tego samego zespo§u mogŸ dzia§aó osoby o z§ych intencjach, które próbujŸ manipulowaó innymi cz£ĺciami systemu. To bardzo niebezpieczne podejĺcie, którego efektem jest zaĺmiecanie kodu wieloma testami chroniŸcymi przed wyimaginowanymi zagroŗeniami. W ten sposób kod staje si£ brzydki, wielki i powolny. Jeĺli kod jest brzydki, to §atwo chowajŸ si£ w nim b§£dy. Jeĺli jest wielki, to z pewnoĺciŸ nie b£dzie dobrze przetestowany, a powolnoĺó zach£ca do uŗywania skrótów i z§ych praktyk. Te ostatnie naleŗŸ do najcz£stszych ŕróde§ luk w zabezpieczeniach. Uwaŗam, ŗe jedynym trwa§ym rozwiŸzaniem problemów zabezpieczeħ jest prosty model bezpieczeħstwa stosowany systematycznie przez wysokiej jakoĺci sprz£t i/lub oprogramowanie w odniesieniu do wybranych interfejsów. Musi istnieó obszar za barierŸ, gdzie moŗna pisaó kod prosto, elegancko i wydajnie bez obaw, ŗe losowe fragmenty kodu zniszczŸ losowe fragmenty innego kodu. Tylko w takim przypadku b£dziemy mogli skupió si£ na poprawnoĺci, jakoĺci i prawdziwej wydajnoĺci. Zak§adanie, ŗe kaŗdy moŗe spreparowaó niezaufane wywo§anie zwrotne, wtyczk£ (ang. plug-in), przeciŸŗonŸ metod£ czy cokolwiek innego, jest po prostu g§upie. Musimy odróŗnió kod, który jest zabezpieczony przed oszustwami, od kodu, który zabezpiecza si£ przed sytuacjami nadzwyczajnymi. Nie sŸdz£, aby moŗna by§o stworzyó j£zyk programowania, który by§by ca§kowicie bezpieczny, a jednoczeĺnie przydatny w praktycznych zastosowaniach. Oczywiĺcie wszystko zaleŗy od definicji s§ów „bezpieczeħstwo” i „system”. Byó moŗe §atwiej 20 R O Z D Z I A « P I E R W S Z Y uzyskaó bezpieczeħstwo systemów w j£zyku specyficznym dla konkretnej dziedziny. MojŸ dziedzinŸ zainteresowania jest jednak programowanie systemowe (w bardzo szerokim znaczeniu tego terminu), w§Ÿcznie z programowaniem systemów wbudowanych. Uwaŗam, ŗe w stosunku do tego, co oferuje C++, moŗna by poprawió bezpieczeħstwo typologiczne (ang. type safety) i z pewnoĺciŸ b£dzie ono poprawione, ale to tylko cz£ĺó problemu: bezpieczeħstwo typologiczne nie jest toŗsame z bezpieczeħstwem w ogóle. Osoby programujŸce w C++, które uŗywajŸ wielu nieopakowanych tablic, operacji rzutowania oraz niestrukturalnych operacji new i delete, same proszŸ si£ o k§opoty. Osoby te pozosta§y na etapie stylu programowania z lat osiemdziesiŸtych. Aby dobrze korzystaó z C++, trzeba stosowaó styl programowania, w którym jest jak najmniej naruszeħ bezpieczeħstwa typologicznego, a zasoby (§Ÿcznie z pami£ciŸ) sŸ zarzŸdzane w prosty i systematyczny sposób. Czy poleci¬by pan j¥zyk C++ do tworzenia niektórych systemów, na przyk¬ad oprogramowania systemowego i aplikacji wbudowanych, mimo Şe praktycy niech¥tnie wykorzystuj¡ go w tych zastosowaniach? Bjarne: Oczywiĺcie, ŗe poleci§bym C++, a poza tym nie wszyscy sŸ niech£tni temu j£zykowi. W§aĺciwie nie zauwaŗy§em zbytniej niech£ci wykorzystywania C++ w tych obszarach, poza naturalnŸ niech£ciŸ do wypróbowywania czegoĺ nowego w instytucjach o ugruntowanej pozycji. Powiedzia§bym nawet, ŗe obserwuj£ sta§y i znaczŸcy wzrost popularnoĺci j£zyka C++. Dla przyk§adu — pomaga§em pisaó wskazówki kodowania dla kluczowego oprogramowania myĺliwca Joint Strike Fighter (JSF) firmy Lockheed Martin. To samolot, którego oprogramowanie jest napisane w ca§oĺci w C++. Czytelnicy najprawdopodobniej nie znajŸ si£ na wojskowych samolotach, ale w sposobach uŗywania j£zyka C++ nie ma nic szczególnie militarnego. W niespe§na rok z moich stron internetowych ĺciŸgni£to grubo ponad 100 000 kopii regu§ kodowania JSF++. Z mojej wiedzy wynika, ŗe informacje te interesowa§y g§ównie programistów niewojskowych systemów wbudowanych. C++ jest uŗywany do projektowania systemów wbudowanych od 1984 roku. W tym j£zyku stworzono wiele przydatnych gadŗetów, a liczba zastosowaħ j£zyka dynamicznie wzrasta. Przyk§adami mogŸ byó telefony komórkowe z systemami Symbian lub Motorola, urzŸdzenia iPod oraz systemy GPS. Osobiĺcie szczególnie podoba mi si£ zastosowanie C++ w lŸdownikach Mars Rovers, w których j£zyk C++ wykorzystano do analizy scen i autonomicznych podsystemów kontroli jazdy, wi£kszoĺci naziemnych systemów komunikacyjnych oraz przetwarzania obrazów. Osoby przekonane o tym, ŗe j£zyk C musi byó bardziej wydajny niŗ C++, odsy§am do mojego artyku§u „Learning Standard C++ as a New Language”1 [C/C++ Users Journal, maj 1999], w którym zamieĺci§em krótki opis filozofii projektu i zaprezentowa§em wyniki prostych eksperymentów. Techniczny raport na temat 1 http://www.open-std.org/JTC1/sc22/wg21/docs/TR18015.pdf. C + + 21 wydajnoĺci opublikowa§ takŗe komitet standaryzacyjny ISO zajmujŸcy si£ j£zykiem C++. W raporcie podj£to kwestie wielu problemów i mitów zwiŸzanych z takimi zastosowaniami C++, w których wydajnoĺó ma znaczenie. Autorzy artyku§u zwrócili szczególnŸ uwag£ na problematyk£ systemów wbudowanych. (Tekst moŗna znaleŕó w internecie — wystarczy poszukaó frazy Technical Report on C++ Performance). J¡dra systemów Linux lub BSD w dalszym ci¡gu s¡ pisane w j¥zyku C. Dlaczego ich projektanci nie zdecydowali si¥ przejŁý na C++? Czy istnieje jakiŁ problem z paradygmatem obiektowym? Bjarne: W wi£kszoĺci przypadków powodem jest konserwatyzm i si§a inercji. Poza tym kompilator GCC wolno dojrzewa§. Wydaje si£, ŗe niektóre osoby ze spo§ecznoĺci j£zyka C wykazujŸ niemal celowŸ ignorancj£ popartŸ wieloletnim doĺwiadczeniem. Od dziesi£cioleci j£zyk C++ jest uŗywany do tworzenia systemów operacyjnych, oprogramowania systemowego, a nawet twardych systemów czasu rzeczywistego oraz programów o kluczowym znaczeniu dla bezpieczeħstwa. Oto kilka przyk§adów: Symbian, OS/400 i K42 firmy IBM, BeOS oraz cz£ĺciowo Windows. Istnieje równieŗ wiele programów open source napisanych w C++ (na przyk§ad KDE). Widz£, ŗe utoŗsamia pan j£zyk C++ z programowaniem obiektowym. C++ nie jest i nigdy nie mia§ byó j£zykiem, w którym stosuje si£ wy§Ÿcznie techniki programowania obiektowego. W 1995 roku napisa§em artyku§ „Why C++ is not just an Object-Oriented Programming Language”. Jest on dost£pny w internecie2. IdeŸ j£zyka C++ by§o — i jest niŸ nadal — wspieranie wielu stylów programowania (paradygmatów, jeĺli woli pan uŗywaó trudnych s§ów) oraz ich kombinacji. W kontekĺcie wysokiej wydajnoĺci i bliskoĺci sprz£tu oprócz programowania obiektowego najwaŗniejszym spoĺród innych paradygmatów jest uŗywanie technik programowania generycznego (na jego okreĺlenie czasami uŗywa si£ skrótu GP — od ang. Generic Programming). Typowa biblioteka C++ standardu ISO — STL — zawierajŸca framework dla algorytmów i kontenerów to w wi£kszym stopniu techniki GP niŗ OO (od ang. Object Oriented). Programowanie generyczne, w typowym dla j£zyka C++ stylu opartym na intensywnym wykorzystywaniu szablonów, stosuje si£ powszechnie wsz£dzie tam, gdzie jest potrzebna zarówno abstrakcja, jak i wydajnoĺó. Nigdy nie spotka§em si£ z programem, który by§by lepiej napisany w C niŗ w C++. Nie sŸdz£, aby taki program w ogóle móg§ istnieó. W najgorszym razie moŗna pisaó kod C++ w stylu zbliŗonym do j£zyka C. Nic nie zmusza programistów do przesadnego wykorzystywania wyjŸtków, hierarchii klas czy szablonów. Dobry programista wykorzystuje zaawansowane w§asnoĺci tam, gdzie pozwalajŸ one na bardziej bezpoĺrednie wyraŗanie idei i nie zmuszajŸ do ponoszenia zb£dnych kosztów. 2 http://www.research.att.com/~bs/oopsla.pdf. 22 R O Z D Z I A « P I E R W S Z Y Dlaczego programiŁci mieliby przenosiý kod z j¥zyka C do C++? Jakie korzyŁci mog¡ wynikn¡ý z zastosowania C++ jako j¥zyka programowania generycznego? Bjarne: Wydaje mi si£, ŗe zak§ada pan, jakoby kod najpierw by§ pisany w j£zyku C, a programista zaczyna§ pisanie wy§Ÿcznie w j£zyku C. W wielu przypadkach programów C++ i programistów C++ (myĺl£, ŗe juŗ od d§ugiego czasu dotyczy to wi£kszoĺci sytuacji) tak nie jest. Niestety podejĺcie polegajŸce na wychodzeniu od j£zyka C zdarza si£ w wielu kr£gach, ale na szcz£ĺcie nie jest juŗ czymĺ, co przyjmuje si£ za pewnik. Ktoĺ moŗe przejĺó z j£zyka C na C++ dlatego, ŗe obs§uga stylu programowania, którŸ realizowa§ wczeĺniej w j£zyku C, jest lepsza w C++ niŗ w C. Kontrola typów w j£zyku C++ jest bardziej ĺcis§a (nie moŗna zapomnieó zadeklarowaó funkcji lub typów jej argumentów), istnieje takŗe bezpieczne typologicznie wsparcie notacji wielu popularnych operacji, takich jak tworzenie obiektów (w§Ÿcznie z inicjalizacjŸ) czy sta§ych. Znam programistów, którzy w§aĺnie z tych powodów przeszli na j£zyk C++ i sŸ bardzo zadowoleni, ŗe uda§o im si£ pozbyó wielu problemów. Zwykle takiemu przejĺciu towarzyszy adopcja niektórych bibliotek j£zyka C++, czasami obiektowych — na przyk§ad standardowej biblioteki obs§ugi wektorów, biblioteki obs§ugi interfejsu GUI oraz niektórych bibliotek specyficznych dla aplikacji. Uŗycie niestandardowego typu, na przyk§ad vector, string czy complex, nie wymaga zmiany paradygmatu. Moŗna po prostu, jeĺli si£ tego chce, korzystaó z nich tak jak z typów wbudowanych. Czy ktoĺ, kto stosuje konstrukcj£ std::vector, uŗywa technik OO? Powiedzia§bym, ŗe nie. Czy ktoĺ, kto uŗywa mechanizmów obs§ugi interfejsu GUI j£zyka C++, ale nie dodaje nowych funkcji, uŗywa technik OO? Sk§aniam si£ do odpowiedzi twierdzŸcej, poniewaŗ uŗywanie ich zwykle wymaga od uŗytkowników zrozumienia i pos§ugiwania si£ mechanizmami dziedziczenia. Wykorzystanie C++ jako j£zyka programowania generycznego daje programiĺcie dost£p do gotowych standardowych kontenerów i algorytmów (w ramach standardowej biblioteki). Jest to wielkie udogodnienie w przypadku wielu zastosowaħ i wejĺcie na wyŗszy poziom abstrakcji w porównaniu z j£zykiem C. Poza tym programiĺci mogŸ korzystaó z bibliotek, na przyk§ad Boost, oraz stosowaó niektóre techniki programowania funkcyjnego w§aĺciwe programowaniu generycznemu. Myĺl£ jednak, ŗe pytanie jest troch£ mylŸce. Nie chc£ przedstawiaó j£zyka C++ jako j£zyka OO lub j£zyka GP. Chcia§bym raczej pokazaó, ŗe jest to j£zyk dajŸcy dost£p do w§asnoĺci takich jak: x programowanie w stylu j£zyka C, x abstrakcja danych, x programowanie obiektowe, x programowanie generyczne. C + + 23 Co najwaŗniejsze, j£zyk ten obs§uguje wiele stylów programowania (programowanie wieloparadygmatowe — jeĺli ktoĺ woli) i jest ukierunkowany na programowanie systemowe. Programowanie obiektowe i wspó§bieŝnoĿø Przeci¥tna z¬oŞonoŁý i rozmiary (licz¡c w wierszach kodu) oprogramowania wydaj¡ si¥ rozrastaý z roku na rok. Czy techniki programowania obiektowego dobrze komponuj¡ si¥ w tej rzeczywistoŁci, czy teŞ tylko bardziej wszystko komplikuj¡? Mam wraŞenie, Şe d¡Şenie do tworzenia obiektów wielokrotnego uŞytku komplikuje wiele rzeczy, a poza tym podwaja pracoch¬onnoŁý. Po pierwsze, trzeba zaprojektowaý narz¥dzie daj¡ce si¥ wielokrotnie wykorzystaý. PóŜniej, kiedy zajdzie koniecznoŁý wprowadzenia zmian, trzeba b¥dzie napisaý coŁ, co dok¬adnie wype¬ni luk¥ pozostawion¡ przez poprzedni¡ wersj¥, a to oznacza ograniczenia dla rozwi¡zania. Bjarne: To dobry opis powaŗnego problemu. OO to zbiór technik gwarantujŸcych duŗe moŗliwoĺci. MogŸ one byó pomocne, ale ŗeby by§y pomocne, muszŸ byó dobrze wykorzystywane i stosowane w odniesieniu do takich problemów, dla których techniki te majŸ coĺ do zaoferowania. Zaprojektowanie dobrej klasy bazowej (interfejsu dla wielu nieznanych wczeĺniej klas) wymaga umiej£tnoĺci przewidywania i doĺwiadczenia. Jest to powaŗny problem podczas tworzenia kodu w ca§oĺci bazujŸcego na dziedziczeniu z wykorzystaniem interfejsów kontrolowanych statycznie. SkŸd projektant klasy bazowej (klasy abstrakcyjnej, interfejsu czy jak to nazwiemy) ma wiedzieó, ŗe uwzgl£dni§ wszystko, co jest potrzebne dla wszystkich klas, które w przysz§oĺci b£dŸ dziedziczy§y z klasy bazowej? SkŸd ma wiedzieó, ŗe to, co zaprojektuje, b£dzie moŗna sensownie zaimplementowaó we wszystkich klasach, które w przysz§oĺci b£dŸ dziedziczy§y z jego klasy bazowej? Jak ma si£ dowiedzieó, ŗe zaprojektowana klasa bazowa nie b£dzie powaŗnie kolidowa§a z czymĺ, co jest wymagane przez pewne klasy, które w przysz§oĺci b£dŸ dziedziczy§y z jego klasy bazowej? Ogólnie rzecz biorŸc, nie ma moŗliwoĺci, by si£ tego dowiedzieó. W ĺrodowisku, w którym moŗemy wymusió nasz projekt, programiĺci dostosujŸ si£ — cz£sto poprzez pisanie ma§o eleganckich obejĺó. Jeĺli nie ma organu koordynujŸcego, powstaje wiele niekompatybilnych interfejsów dla tego samego zestawu funkcji. Nie moŗna rozwiŸzaó tych problemów w sposób ogólny, ale programowanie generyczne wydaje si£ byó dobrym rozwiŸzaniem w wielu waŗnych obszarach, w których podejĺcie obiektowe si£ nie sprawdza. Przyk§adem godnym przytoczenia sŸ proste kontenery: za pomocŸ hierarchii dziedziczenia nie moŗna dobrze wyrazió poj£cia bycia elementem. Nie moŗna równieŗ dobrze wyrazió poj£cia bycia kontenerem. Relacje te mogŸ jednak dostarczyó skutecznych rozwiŸzaħ za pomocŸ programowania generycznego. Przyk§adem moŗe byó biblioteka STL (wchodzŸca w sk§ad standardowej biblioteki C++). 24 R O Z D Z I A « P I E R W S Z Y Czy to jest problem specyficzny dla j¥zyka C++, czy teŞ w równym stopniu dotyczy on innych j¥zyków programowania? Bjarne: Problem jest wspólny dla wszystkich j£zyków, które bazujŸ na statycznie kontrolowanych interfejsach hierarchii klas. Przyk§adem sŸ j£zyki C++, Java i C#. Problem ten nie dotyczy j£zyków z dynamicznŸ kontrolŸ typów, takich jak Smalltalk czy Python. W j£zyku C++ t£ kwesti£ moŗna rozwiŸzaó za pomocŸ programowania generycznego. Dobrym przyk§adem sŸ kontenery C++ i algorytmy naleŗŸce do standardowej biblioteki. KluczowŸ cechŸ j£zyka sŸ w tym przypadku szablony dostarczajŸce model póŕnej kontroli typów. Jest to odpowiednik mechanizmu dynamicznej kontroli typów, tyle ŗe w fazie kompilacji, a nie wykonywania programu. Wprowadzone ostatnio do j£zyków Java i C# typy generyczne sŸ próbŸ pójĺcia w kierunku wyznaczonym przez C++. Wed§ug mojej opinii cz£sto nies§usznie mówi si£ o nich jako o usprawnieniu szablonów. Szczególnie popularnŸ technikŸ jest refaktoryzacja, która polega na próbie rozwiŸzania problemu technikŸ si§owŸ poprzez przeorganizowanie kodu, w przypadku gdy poczŸtkowy projekt interfejsu by§ nieprawid§owy. JeŁli jest to ogólny problem programowania obiektowego, to jak¡ mamy pewnoŁý, Şe zalety programowania OO s¡ wi¥ksze niŞ wady wynikaj¡ce ze stosowania tej techniki? Byý moŞe problem z trudnoŁci¡ uzyskania dobrego projektu obiektowego jest Ŝród¬em wszystkich innych problemów. Bjarne: Istnienie problemu w niektórych lub nawet w wielu przypadkach nie zmienia faktu, ŗe wiele doskona§ych, wydajnych i §atwych do zarzŸdzania systemów napisano w j£zykach obiektowych. Techniki obiektowe naleŗŸ do podstawowych sposobów projektowania systemów, a interfejsy kontrolowane statycznie oprócz wad majŸ równieŗ zalety. W dziedzinie wytwarzania oprogramowania nie istnieje jedna recepta na wszystkie problemy. Projektowanie jest trudne pod wieloma wzgl£dami. Programiĺci cz£sto nie doceniajŸ intelektualnych i praktycznych trudnoĺci zwiŸzanych z tworzeniem rozbudowanych systemów zawierajŸcych elementy oprogramowania. Tworzenie takich systemów nie sprowadza si£ i nigdy nie b£dzie si£ sprowadzaó do mechanicznego procesu produkcyjnego. Do stworzenia stosunkowo duŗego systemu niezb£dne sŸ kreatywnoĺó, stosowanie zasad inŗynierskich oraz ewolucyjne zmiany. Czy istniej¡ powi¡zania pomi¥dzy paradygmatem programowania obiektowego a wspó¬bieŞnoŁci¡? Czy coraz wi¥ksze potrzeby poprawy wspó¬bieŞnoŁci doprowadz¡ do zmiany implementacji, czy natury projektów obiektowych? Bjarne: Od bardzo d§ugiego czasu istnieje powiŸzanie pomi£dzy programowaniem obiektowym a wspó§bieŗnoĺciŸ. W Simuli 67, j£zyku programowania, w którym po raz pierwszy by§y bezpoĺrednio dost£pne techniki programowania obiektowego, istnia§y równieŗ mechanizmy do przedstawiania operacji wspó§bieŗnych. C + + 25 PierwszŸ bibliotekŸ C++ by§a biblioteka obs§ugujŸca mechanizm, który dziĺ nazwalibyĺmy wŸtkami. W Bell Labs juŗ w 1988 roku wykorzystywaliĺmy j£zyk C++ na komputerze szeĺcioprocesorowym i nie byliĺmy jedynymi, którzy uŗywali go w takich zastosowaniach. W latach dziewi£ódziesiŸtych istnia§o co najmniej kilkadziesiŸt eksperymentalnych dialektów j£zyka C++ oraz bibliotek zajmujŸcych si£ problemami programowania rozproszonego i równoleg§ego. Wspó§czesne zach§yĺni£cie si£ systemami wielordzeniowymi nie jest moim pierwszym kontaktem ze wspó§bieŗnoĺciŸ. Przetwarzanie rozproszone by§o tematem mojej pracy doktorskiej i od tamtych czasów ĺledz£ t£ dziedzin£. Ludzie, którzy po raz pierwszy stykajŸ si£ ze wspó§bieŗnoĺciŸ, wieloma rdzeniami itp., cz£sto robiŸ b§Ÿd, nie doceniajŸc kosztów uruchamiania operacji na innym procesorze. Koszt uruchomienia operacji na innym procesorze (rdzeniu) oraz dost£pu tej operacji do danych w pami£ci procesora wywo§ujŸcego (kopiowanie bŸdŕ teŗ zdalny dost£p) moŗe byó tysiŸc (lub wi£cej) razy wi£kszy niŗ koszt zwyk§ego wywo§ania funkcji. Poza tym ryzyko pope§nienia b§£dów okazuje si£ duŗo wyŗsze, jeĺli zastosuje si£ wspó§bieŗnoĺó. Aby skutecznie wykorzystaó udost£pniane przez sprz£t moŗliwoĺci przetwarzania równoleg§ego, trzeba przemyĺleó organizacj£ oprogramowania. Na szcz£ĺcie moŗemy wykorzystaó wyniki badaħ prowadzonych przez dziesi£ciolecia (które jednak mogŸ nas równieŗ wprowadzió w b§Ÿd). Ogólnie rzecz biorŸc, jest tak wiele badaħ, ŗe niemal niemoŗliwe okazuje si£ stwierdzenie, które sŸ wartoĺciowe, a tym bardziej — które sŸ najlepsze. Dobrym punktem wyjĺcia moŗe byó artyku§ na temat j£zyka Emerald, wyg§oszony na konferencji HOPL-III. J£zyk ten by§ pierwszym, który zajmowa§ si£ interakcjŸ pomi£dzy problemami j£zyka a problemami systemowymi z uwzgl£dnieniem kosztów. WaŗnŸ rzeczŸ jest równieŗ rozróŗnienie pomi£dzy równoleg§ym przetwarzaniem danych, stosowanym od dziesi£cioleci do wykonywania obliczeħ naukowych (g§ównie w j£zyku FORTRAN), a uruchamianiem komunikujŸcych si£ ze sobŸ jednostek zwyk§ego sekwencyjnego kodu (na przyk§ad procesów lub wŸtków) na wielu procesorach. Uwaŗam, ŗe aby j£zyk programowania móg§ zdobyó powszechnŸ akceptacj£ we wspó§czesnym ĺwiecie wielu rdzeni i klastrów, powinien obs§ugiwaó oba rodzaje wspó§bieŗnoĺci, a najlepiej jeĺli obs§ugiwa§by po kilka odmian kaŗdego z nich. Nie jest to §atwe, a problemy wykraczajŸ poza tradycyjne sprawy dotyczŸce j£zyków programowania — trzeba §Ÿcznie uwzgl£dnió problemy zwiŸzane z j£zykiem, systemami i aplikacjami. Czy j¥zyk C++ jest przygotowany do obs¬ugi wspó¬bieŞnoŁci? OczywiŁcie moŞna stworzyý biblioteki, które b¥d¡ obs¬ugiwa¬y wszystko, ale czy j¥zyk i standardowa biblioteka wymagaj¡ powaŞnych zmian pod k¡tem obs¬ugi wspó¬bieŞnoŁci? Bjarne: Jest prawie przygotowany. Wersja C++0x b£dzie przygotowana. Aby j£zyk móg§ obs§ugiwaó wspó§bieŗnoĺó, musi przede wszystkim mieó dok§adnie zdefiniowany model pami£ci. Dzi£ki temu autorzy kompilatora mogŸ skorzystaó z nowoczesnego sprz£tu (wyposaŗonego w potoki, duŗe pami£ci podr£czne, bufory przewidywania 26 R O Z D Z I A « P I E R W S Z Y rozga§£zieħ, mechanizmy statycznego i dynamicznego przestawiania instrukcji itp.). Wtedy wystarczŸ niewielkie rozszerzenia j£zyka: lokalna pami£ó masowa z obs§ugŸ wŸtków oraz atomowe typy danych. Nast£pnie moŗna dodaó obs§ug£ wspó§bieŗnoĺci w postaci bibliotek. Naturalnie pierwszŸ nowŸ bibliotekŸ standardowŸ b£dzie biblioteka obs§ugi wŸtków, umoŗliwiajŸca przenoĺne programowanie pomi£dzy systemami, na przyk§ad Linux i Windows. Oczywiĺcie takie biblioteki istniejŸ od wielu lat, ale nie sŸ to biblioteki standardowe. WŸtki wraz z pewnŸ formŸ blokowania majŸcŸ na celu unikni£cie wyĺcigów to jeden z najgorszych sposobów bezpoĺredniej obs§ugi wspó§bieŗnoĺci. Jednak w j£zyku C++ taki mechanizm jest potrzebny, aby moŗna by§o obs§uŗyó istniejŸce aplikacje oraz aby j£zyk móg§ spe§nió swojŸ rol£ — rol£ systemowego j£zyka programowania w tradycyjnych systemach operacyjnych. Prototypy takiej biblioteki istniejŸ — powsta§y na podstawie wielu lat aktywnego uŗytkowania j£zyka. Jednym z kluczowych problemów wspó§bieŗnoĺci jest sposób opakowania zadania, by mog§o ono byó wykonane wspó§bieŗnie z innymi zadaniami. Przewiduj£, ŗe w j£zyku C++ rozwiŸzaniem tego problemu b£dzie obiekt funkcyjny. Obiekt moŗe zawieraó potrzebne dane i przekazywaó je wed§ug potrzeb. Standard C++98 dobrze obs§uguje ten mechanizm dla nazwanych operacji (nazwanych klas, z których egzemplifikujemy obiekty funkcyjne). Technika ta jest teŗ powszechnie stosowana do parametryzacji w bibliotekach generycznych (na przyk§ad STL). W standardzie C++0x u§atwiono pisanie prostych jednorazowych obiektów funkcyjnych poprzez wprowadzenie funkcji lambda, które mogŸ byó pisane w kontekstach wyraŗeħ (na przyk§ad jako argumenty funkcji) i odpowiednio generujŸ obiekty funkcji (domkni£cia). Nast£pne kroki sŸ bardziej interesujŸce. Natychmiast po opublikowaniu standardu C++0x komisja planuje wydanie technicznego raportu na temat bibliotek. Niemal na pewno biblioteki b£dŸ obs§ugiwaó pule wŸtków oraz jakŸĺ form£ „wykradania” pracy. Mam tu na myĺli to, ŗe b£dzie istnia§ standardowy mechanizm pozwalajŸcy uŗytkownikowi na wspó§bieŗne wykonywanie stosunkowo niewielkich jednostek pracy (zadaħ). Dzi£ki korzystaniu z tego mechanizmu uŗytkownik nie b£dzie si£ musia§ martwió tworzeniem wŸtków, ich niszczeniem, blokadami itp. Mechanizmy te b£dŸ prawdopodobnie wbudowane w obiekty funkcyjne jako zadania. Poza tym uľytkownik b£dzie móg§ korzystaó z mechanizmów komunikacji mi£dzy geograficznie zdalnymi procesami za pomocŸ gniazd, strumieni wejĺcia-wyjĺcia itp., podobnych do tych oferowanych w bibliotece boost::networking. W mojej opinii wi£kszoĺó interesujŸcych elementów wspó§bieŗnoĺci pojawi si£ w postaci wielu bibliotek obs§ugujŸcych logicznie roz§Ÿczne modele wspó§bieŗnoĺci. C + + 27 Wiele wspó¬czesnych systemów jest podzielonych na komponenty i rozproszonych w sieci. Era aplikacji webowych i aplikacji mashup moŞe podkreŁliý ten trend. Czy w j¥zyku powinny si¥ znaleŜý mechanizmy obs¬uguj¡ce te aspekty pracy sieciowej? Bjarne: Istnieje wiele form wspó§bieŗnoĺci. Celem niektórych z nich jest poprawa przepustowoĺci lub czasu odpowiedzi programu na pojedynczym komputerze bŸdŕ klastrze, niektóre majŸ na celu obs§ug£ geograficznej dystrybucji, a jeszcze inne znajdujŸ si£ poniŗej poziomu, jakim zwykle zajmujŸ si£ programiĺci (potoki, pami£ó podr£czna itp.). Standard C++0x dostarczy zbioru mechanizmów i gwarancji zabezpieczajŸcych programistów przed niskopoziomowymi szczegó§ami. Wprowadza on model maszyny, który b£dzie móg§ pe§nió rol£ kontraktu pomi£dzy architektami komputera a autorami kompilatorów. Dostarczy równieŗ bibliotek£ obs§ugi wŸtków, w której znajdzie si£ proste odwzorowanie kodu na procesory. Skorzystanie z tych podstaw pozwala dostarczyó inne modele za poĺrednictwem bibliotek. Chcia§bym, aby w bibliotece standardu C++0x znalaz§y si£ prostsze w uŗytkowaniu, wyŗejpoziomowe modele wspó§bieŗnoĺci, ale teraz wydaje si£ to ma§o prawdopodobne. Póŕniej — mam nadziej£, ŗe wkrótce po opublikowaniu standardu C++0x — pojawi si£ wi£cej bibliotek wyspecyfikowanych w raporcie technicznym: pule wŸtków i obiekty future, a takŗe biblioteka obs§ugi strumieni wejĺcia-wyjĺcia w sieci rozleg§ej (na przyk§ad TCP/IP). Takie biblioteki istniejŸ, ale nie wszyscy uwaŗajŸ, ŗe sŸ one na tyle dobrze wyspecyfikowane, aby mog§y staó si£ standardowe. Wiele lat temu mia§em nadziej£, ŗe standard C++0x zajmie si£ starymi dla j£zyka C++ problemami dystrybucji poprzez wyspecyfikowanie standardowej formy serializacji, ale tak si£ nie sta§o. A zatem spo§ecznoĺó programistów j£zyka C++ b£dzie zmuszona rozwiŸzywaó bardziej wysokopoziomowe problemy przetwarzania rozproszonego i aplikacji rozproszonych za pomocŸ niestandardowych bibliotek i/lub platform framework (na przyk§ad CORBA lub .NET). Pierwsza biblioteka j£zyka C++ (w rzeczywistoĺci pierwszy kod w j£zyku C z obs§ugŸ klas) dostarcza§a lekkiej obs§ugi wspó§bieŗnoĺci. Przez lata w C++ powsta§y setki bibliotek i frameworków obs§ugujŸcych przetwarzanie wspó§bieŗne, równoleg§e i rozproszone, ale spo§ecznoĺó nie zdo§a§a si£ porozumieó co do standardów. Przypuszczam, ŗe cz£ĺciowo problem ten wynika z tego, ŗe zrobienie czegoĺ powaŗnego w tej dziedzinie wymaga znacznych nak§adów finansowych, a wielcy gracze wolŸ wydawaó pieniŸdze na w§asne zastrzeŗone biblioteki, frameworki i j£zyki. Nie jest to dobre dla spo§ecznoĺci j£zyka C++ jako ca§oĺci. 28 R O Z D Z I A « P I E R W S Z Y Przysz§oĿø Czy kiedykolwiek powstanie standard C++ 2.0? Bjarne: To zaleŗy, co pan rozumie przez „C++ 2.0”. Jeĺli oczekuje pan nowego j£zyka, stworzonego prawie od podstaw, zawierajŸcego wszystko, co najlepsze w C++, i pozbawionego wszystkiego tego, co z§e (dla okreĺlonych definicji tego, co dobre, i tego, co z§e), to moja odpowiedŕ brzmi: „Nie wiem”. Chcia§bym, aby powsta§ nowy j£zyk wywodzŸcy si£ z tradycji C++, ale nie widz£ takiego na horyzoncie, zatem pozwoli pan, ŗe skoncentruj£ si£ na nast£pnym standardzie ISO j£zyka C++, znanym pod nazwŸ C++0x. Dla wielu osób b£dzie to C++ 2.0, poniewaŗ dostarczy nowych w§asnoĺci j£zyka i nowych standardowych bibliotek, ale jednoczeĺnie b£dzie niemal w 100 zgodny z C++98. Nazwaliĺmy go C++0x z nadziejŸ, ŗe nazwa ta przekszta§ci si£ w C++09. Jeĺli si£ spóŕnimy — w zwiŸzku z czym x b£dzie musia§ przyjŸó wartoĺó cyfry szesnastkowej — to zarówno ja, jak i inni cz§onkowie zespo§u b£dziemy smutni i zak§opotani. Standard C++0x b£dzie niemal w 100 zgodny z C++98. Naszym celem nie jest doprowadzenie do tego, by istniejŸcy kod przesta§ dzia§aó. Najbardziej znaczŸce niezgodnoĺci wynikajŸ z uŗycia kilku nowych s§ów kluczowych, takich jak static_assert, constexpr i concept. Staraliĺmy si£ zminimalizowaó ich oddzia§ywanie na kod, wybraliĺmy wi£c nowe s§owa kluczowe, które nie sŸ cz£sto wykorzystywane. Najwaŗniejsze usprawnienia to: x Obs§uga nowoczesnych architektur komputerów i wspó§bieŗnoĺci: model maszyny, biblioteka wŸtków, lokalna pami£ó masowa wŸtków i operacje atomowe oraz mechanizmy asynchronicznego zwracania wartoĺci (obiekty future). x Lepsza obs§uga programowania generycznego: typ concept (system typologiczny dla typów, kombinacji typów oraz kombinacji typów i liczb integer) umoŗliwiajŸcy lepszŸ kontrol£ definicji i zastosowaħ szablonów oraz lepsze przeciŸŗanie szablonów. Dedukcja typów bazujŸca na inicjalizatorach (auto), uogólnione listy inicjalizacyjne, uogólnione wyraŗenia sta§e (constexpr), wyraŗenia lambda i wiele innych. x Wiele drobnych rozszerzeħ j£zyka, takich jak statyczne asercje, semantyka przenoszenia (ang. move semantics), poprawione enumeracje, nazwa pustego wskaŕnika (nullptr) itp. x Nowe biblioteki standardowe obs§ugi dopasowywania wyraŗeħ regularnych, tablic skrótów (na przyk§ad unordered_map), inteligentnych wskaŕników itp. Szczegó§owe informacje moŗna znaleŕó w witrynie internetowej komitetu standaryzacyjnego C++3. Sumaryczne zestawienie zamieĺci§em na prowadzonej przeze mnie stronie internetowej C++0x FAQ4. 3 http://www.open-std.org/jtc1/sc22/wg21/. 4 http://www.research.att.com/~bs/C++0xFAQ.html. C + + 29 Warto zwróció uwag£, ŗe kiedy mówi£ o zachowaniu dzia§ania kodu, odnosz£ si£ do rdzenia j£zyka oraz biblioteki standardowej. Stary kod przestanie oczywiĺcie dzia§aó, jeĺli wykorzystuje niestandardowe rozszerzenia od jakiegoĺ dostawcy kompilatora lub antyczne niestandardowe biblioteki. Z mojego doĺwiadczenia wynika, ŗe jeĺli ktoĺ skarŗy si£ na to, ŗe kod przesta§ dzia§aó lub ŗe jest niestabilny, zazwyczaj przyczynŸ sŸ zastrzeŗone w§asnoĺci i biblioteki. Jeĺli na przyk§ad zmienimy system operacyjny, a w programie nie skorzystaliĺmy z jednej z przenoĺnych bibliotek GUI, prawdopodobnie b£dziemy zmuszeni do wykonania pewnych operacji z kodem interfejsu uŗytkownika. Co pana powstrzymuje przed stworzeniem ca¬kowicie nowego j¥zyka? Jakie problemy mia§by rozwiŸzywaó nowy j£zyk? Bjarne: Natychmiast pojawia si£ kilka kluczowych pytaħ: x x Czyje problemy rozwiŸzywa§by ten j£zyk? x Jakie nowoĺci moŗna by wprowadzió (w porównaniu z kaŗdym z istniejŸcych j£zyków)? x Czy nowy j£zyk moŗe byó skutecznie wdroŗony (w ĺwiecie, w którym istnieje wiele j£zyków o mocnej pozycji)? x Czy praca nad nowym j£zykiem ma byó tylko przyjemnym oderwaniem si£ od ci£ŗkiej pracy polegajŸcej na wspomaganiu tworzenia lepszych narz£dzi i systemów? Dotychczas nie uda§o mi si£ w zadowalajŸcy mnie sposób odpowiedzieó na te pytania. Nie oznacza to jednak, ŗe uwaŗam C++ za perfekcyjny w swojej klasie. Nie jest on perfekcyjny. Jestem przekonany, ŗe moŗna by zaprojektowaó j£zyk, który mia§by rozmiary nieprzekraczajŸce jednej dziesiŸtej rozmiaru C++ (niezaleŗnie od sposobu mierzenia rozmiaru) i który w mniejszym lub w wi£kszym stopniu dawa§by te same moŗliwoĺci co C++. Tymczasem tworzenie nowego j£zyka to coĺ wi£cej niŗ tylko powielenie operacji wykonywanych w istniejŸcym j£zyku, tyle ŗe nieco lepiej i nieco bardziej elegancko. Jakie wnioski z lekcji na temat powstania, dalszego rozwoju i przystosowywania si¥ paĮskiego j¥zyka do warunków wspó¬czesnych mog¡ wyci¡gn¡ý programiŁci, którzy tworz¡ systemy komputerowe dziŁ oraz b¥d¡ je tworzyý w najbliŞszej przysz¬oŁci? Bjarne: To doskona§e pytanie — czy potrafimy uczyó si£ z historii? Jeĺli tak, to jak i czego moŗemy si£ nauczyó? W poczŸtkowej fazie tworzenia j£zyka C++ sformu§owa§em zbiór regu§ oczywistych. Moŗna je znaleŕó w ksiŸŗce The Design and Evolution of C++ [Addison-Wesley]. Omówi§em je takŗe w dwóch ref
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Wielkie umysły programowania. Jak myślą i pracują twórcy najważniejszych języków
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: