Wiemy już, jak daleko sięga teoria programowania obiektowego: filozofia vs programowanie. Problemem staje się właściwa jej realizacja. Wybór technologii i języka programowania to proces, na który składa się wiele czynników. Popularność, spełnianie wymagań danego projektu, społeczność stojąca za daną technologią, producent i jego pozycja na rynku, wskaźnik ROI, preferencje własne. Mówiąc o obiektowości i generalnie o architekturze, trzeba zauważyć, że obecnie w wielu projektach czas i wymagania sprawiają, że odchodzi się od czysto obiektowego stylu na rzecz wydajności i efektywności. Np. Ruby On Rails - Ruby to fantastyczny obiektowy język, ale już Railsy i ich architektura pozostawia wiele do życzenia, nie dlatego, że jest zła, ale dlatego, że postawiono tam na realizacje innych celów. Trend pogoni za wydajnością kosztem architektury to tak naprawdę data-oriented design.
Wracając do czystej obiektowości: “Programiści obiektowi dzielą się na dwie kategorie: Smalltalkersi i Ci, którzy tego nie rozumieją.” - Vassili Bykov. Można się z tym zgodzić lub nie. Ale jak powiedział Alan Kay: języki programowania mogą być kategoryzowane według wielu kryteriów: imperatywnych, logicznych, zorientowanych problemowo, itd. Jednak wszystkie zaliczają się bądź to do grupy języków „sklejanych z funkcjonalności” bądź tych z „krystalicznym stylem”. Języki takie jak COBOL, PL/1, ADA, itd. zaliczają się do pierwszej kategorii; LISP, APL, Smalltalk do drugiej. Dlaczego warto się zainteresować Smalltalkiem? Nie ma języka obiektowego o tak prostej, a jednocześnie ekspresyjnej syntaktyce.
Architektura i działanie języka Smalltalk jest oparte o wewnętrzną możliwość opisu i reprezentacji wszystkiego za pomocą rekursywnej kompozycji składającej się na blok, kryjący swoją kombinację stanu, i zachowania, z którym interakcja odbywa się tylko i wyłącznie za pomocą wymiany komunikatów.
Co jeśli chodzi o architekturę języka? Powyższy diagram mówi sam za siebie. Smalltalk to język przemyślany, dopracowany i rozwijany od lat 70-tych. Jego dojrzałość to kolejna zaleta. Docenić ją można patrząc chociażby na języki czerpiące od niego jak Python i Ruby. W obydwu proces rozwoju przypomina raczej eksperymenty nastolatka np. “Dziś mamy wersje 2.1 tak? No to jutro stworzymy wersję 5.0, która będzie dopiero cool!”. W Smalltalku rozwój jest zrównoważony, polega na dopracowywaniu języka, nie na tworzeniu miliona jego wersji. Kolejną zaletą Smalltalk jest fakt jego całkowitej integracji z IDE, z którym jest dostarczany, można powiedzieć, że jest to absolutna symbioza. Środowisko to oferuje fantastyczne narzędzia i ich integracje z kodem na poziomie, o którym tylko pomarzyć mogą użytkownicy np. RubyMine.
Oczywiście to, jak i system Imagebased, dla jednych jest wadą, dla innych zaletą, na pewno jest to środowko jedyne w swoim rodzaju. Kolejną rzeczą wartą wyjaśnienia są projekty takie jak PyPy i Rybinius - to fakt - są świetne, bazują na metacyklicznych wirtualnych maszynach. Tyle tylko, że Smalltalk od początku bazuje na metacykliczności, a projekt Rubinius to wierna kopia architektury z implementacji Squeak. Gdyby się tak zastanowić, to nie ma języka obiektowego, który nie czerpałby dziś ze Smaltallka. Co z działką WebDevelopment? Ruby ma Railsy, Smalltalk ma Seaside. Słuszne jest zdanie, że jest to “The heretic web framework”. W pełni obiektowy, bazujący na mechanizmie kontynuacji framework, w którym wszystko tworzone jest w Smalltalku od obiektowej bazy danych poprzez html. Ktoś powie: przecież to nie jest skalowalne. Jest, zajrzyj do projektu GLASS, bazującym na sprawdzonych systemach Gemstone. Paradoksalne kolejny projekt, który jest nowy w społeczności Ruby - Maglev, tutaj używany jest od bardzo dawna.
Czy jest to wszystko czytelne i proste? Oto przykład testu BDD :
Kod Smalltalk:
Michal should not be an instance of: Administrator
Nawet w Ruby nie da się stworzyć tak czytelnego i pięknego kodu.
"W zasadzie nie ma niczego, co możesz zrobić w języku Ruby, czego nie mógłbyś zrobić w języku Smalltalk. Jednak jest mnóstwo rzeczy, które możesz zrobić w Smalltalku, ale nie zrobisz tego w języku Ruby." - RubyIsSmalltalkMinusMinus.
Podsumowując Smalltalk został stworzony, by uczyć ludzi programowania w jak najprostszy i przystępny sposób.Tak naprawdę nieoczekiwanie stał się językiem używanym powszechnie. Nie wpłynęło to jednak na jego podstawowe założenia. Jeśli więc chcesz nauczyć się dobrze projektować systemy w oparciu o paradygmat obiektowy, jest to język, od którego powinieneś zacząć. Najlepiej rozwijająca się obecnie implementacja Smalltalka to Pharo - tu zacznij.
Wracając do czystej obiektowości: “Programiści obiektowi dzielą się na dwie kategorie: Smalltalkersi i Ci, którzy tego nie rozumieją.” - Vassili Bykov. Można się z tym zgodzić lub nie. Ale jak powiedział Alan Kay: języki programowania mogą być kategoryzowane według wielu kryteriów: imperatywnych, logicznych, zorientowanych problemowo, itd. Jednak wszystkie zaliczają się bądź to do grupy języków „sklejanych z funkcjonalności” bądź tych z „krystalicznym stylem”. Języki takie jak COBOL, PL/1, ADA, itd. zaliczają się do pierwszej kategorii; LISP, APL, Smalltalk do drugiej. Dlaczego warto się zainteresować Smalltalkiem? Nie ma języka obiektowego o tak prostej, a jednocześnie ekspresyjnej syntaktyce.
Architektura i działanie języka Smalltalk jest oparte o wewnętrzną możliwość opisu i reprezentacji wszystkiego za pomocą rekursywnej kompozycji składającej się na blok, kryjący swoją kombinację stanu, i zachowania, z którym interakcja odbywa się tylko i wyłącznie za pomocą wymiany komunikatów.
 |
| Źródło: Pharo By Example |
 |
| 1973 rok. System Operacyjny Xerox Alto zbudowany na bazie projektu Smalltalka. Na ekranie widać IDE Smalltalka. |
Czy jest to wszystko czytelne i proste? Oto przykład testu BDD :
Kod Smalltalk:
Michal should not be an instance of: Administrator
Nawet w Ruby nie da się stworzyć tak czytelnego i pięknego kodu.
"W zasadzie nie ma niczego, co możesz zrobić w języku Ruby, czego nie mógłbyś zrobić w języku Smalltalk. Jednak jest mnóstwo rzeczy, które możesz zrobić w Smalltalku, ale nie zrobisz tego w języku Ruby." - RubyIsSmalltalkMinusMinus.
Podsumowując Smalltalk został stworzony, by uczyć ludzi programowania w jak najprostszy i przystępny sposób.Tak naprawdę nieoczekiwanie stał się językiem używanym powszechnie. Nie wpłynęło to jednak na jego podstawowe założenia. Jeśli więc chcesz nauczyć się dobrze projektować systemy w oparciu o paradygmat obiektowy, jest to język, od którego powinieneś zacząć. Najlepiej rozwijająca się obecnie implementacja Smalltalka to Pharo - tu zacznij.
Komentarze
