Umět modifikovat program za běhu je vlastnost, která se na první pohled může zdát jako poměrně zbytečná. Ovšem pro Smalltalk jako pro inkrementálně budovaný systém je naprosto kritická.
Při úpravě stávajícího programu je nutné rozlišit dva různé procesy. Při prvním je rozšiřována stávající struktura systému např. o nové třídy, jsou odstraňovány metody apod. Při této příležitosti nedochází k žádnému překladu bytekódu (pokud není zároveň prováděna i rekompilace metod).
Druhý proces se týká přidávání metod. Ty jsou primárně ukládány ve formátu bytekódu a jejich zdrojový text je podružný. Kód metod musí být nejdříve přeložen kompilátorem a až poté následuje jeho integrace do systému. Kompilaci jako celek nelze považovat za pouhou tvorbu statického bytekódu, protože zkompilovaná metoda je okamžitě pevně provázána se systémem např. prostřednictvím referencí z literálů.
Vyhodnocení výrazu
Pokud máme k dispozici nějaký zdrojový smalltalkovský kód, můžeme jej nechat velice snadno vyhodnotit. Na pozadí pak dojde k jeho překladu do bytekódu a k následnému spuštění. Tento přístup využívají např. příkazy print it, do it apod.
Compiler evaluate: '3 + 4'.
Pokud při překladu zpracovávaného řetězce dojde k chybě, je o tom uživatel informován formou dialogového okna s jejím popisem. To v mnoha případech může být nevhodné, proto máme možnost pomocí některé modifikované varianty metody evaluate: předhodit kompilátoru objekt odchytávající a zpracovávající chybové stavy.
Přidání a zrušení třídy
Na podobnost definice třídy s běžným voláním zpráv jsme již upozorňovali. Je zřejmé, že k vytvoření nebo k úpravě stávající definice třídy stačí toto volání nechat v programu provést jako cokoliv jiného.
Object subclass: #MyClass
instanceVariableNames: 'var1 var2'
classVariableNames: ''
poolDictionaries: ''
category: 'MyClasses'
Zrušení třídy se pak provede jednoduše tak, že se jí pošle zpráva removeFromSystem
MyClass removeFromSystem
Přidání a zrušení metody
Rovněž základní kompilace metod nemůže být snazší. Stačí třídě, jejíž součástí má nová metoda být, zaslat zprávu compile: se zdrojovým textem.
MyClass compile: 'getVar1 ^var1'
Samozřejmě i tato metoda má sofistikovanější varianty, které umožňují odchytávat chybové stavy či zařadit vytvářenou metodu do specifikované kategorie apod.
Pro likvidaci metody stačí využít služeb zprávyremoveSelector:
MyClass removeSelector: #getVar1
Postup pro práci s metodami metatříd je zcela analogický.
MyClass class compile: 'new ^super basicNew initialize' Využití těchto prostředků se zdaleka nemusí omezovat např. pouze na genetické algoritmy. Významnou roli hrají mimo jiné v případech, kdy uživatel nemá k dispozici, ať již z principu, nebo z vůle programátora, běžné nástroje pro vývoj. Kupříkladu pokud pracuje přes webové rozhraní, nebo v okamžiku, kdy chceme dát uživateli možnost jednoduše a často i skrytě dotvářet či modifikovat dle libosti naši aplikaci.
Babylónská rybka
Elegantní a čistý návrh Smalltalku je velkým lákadlem pro nejeden projekt opírající se o velice abstraktní formalismy a koncepty. Ovšem při řešení některých problémů se i tento jazyk může ukázat být příliš neohrabaný oproti logickým či funkcionálním jazykům. V takovém případě bývá kombinace Smalltalku s Prologem či Lispem ideálním řešením čerpajícím to nejlepší z naprosto rozdílných programovacích konceptů.
Pokud zatoužíte po kooperaci s Prologem, existuje několik více či méně použitelných implementací. Poměrně zajímavý je Prolog/V, který vznikl původně pro Smalltalk/V. V integraci se Smalltalkem jde poměrně daleko a k přizpůsobením došlo na obou stranách.
father('John', 'Mary'). "John is the father of Mary"
father('John', 'David').
father('David', 'Jack').
father('Arthur', 'Nancy').
member(x,[x|_]).
member(x,[_|r]) :- member(x,r).
(Family new :? father('John', x))
do: [ :eachAnswer |
Transcript show: (eachAnswer at: 1), ' is a child of John'; cr].
PrologDemo new :? member(''a'',[''a'', ''b'', ''c'']) Příznivci Scheme jistě rovněž nebudou příliš zklamáni.
| prg exp |
prg := '(define map (lambda (f l)
(if (null? l)
''()
(cons (f (car l)) (map f (cdr l))))))
(map (lambda (x) (+ x 1)) ''(1 2 3 4)))'.
exp := Scheme evalString: prg.
Vráceným objektem není řetězec, ale instance třídy SchemePair, takže s dalším zpracováváním ve Smalltalku nejsou problémy.
Implementace Lispu ve Squeaku umožňuje velmi pohodlně zasílat smalltalkovské zprávy, proto ze vzájemné kooperace těchto dvou jazyků lze vytěžit skutečně hodně. Pokud si svůj život bez car a cdr neumíte představit, může vám snad vadit pouze to, že se nejedná o implementaci Smalltalku v Lispu.
| aList |
aList := LispInterpreter evaluateFrom: '
(do
(count)
(setq count 1)
(while
(<= count 100)
do
(send {Transcript} `cr)
(send {Transcript} `show: (send count `printString))
(setq count (+ count 1))))
'. Tím výčet programovacích jazyků použitelných v rámci Squeaku nekončí. Při práci na náročných projektech z oblastí teoretické informatiky zajisté oceníte implementaci Karla. Doslova třešničkou na dortu je pak emulátor stařičkého Smalltalku-72, který daroval autor původního smalltalkovského a squeakovského virtuálního stroje Dan Ingalls k narozeninám Alanu Kayovi.
Budoucnost Squeaku
Within one month we had a port to Windows in Germany, and a port to Unix in France.
Dan Ingalls
V současné době je Squeak bezesporu nejdynamičtěji se vyvíjející implementací Smalltalku. Díky tomu, že za jeho vývojem stojí lidé, kteří Smalltalk vymysleli, a jedná se o čistokrevný Smalltalk-80, si velmi rychle vydobyl zasloužený respekt.
Vývoj Squeaku směřuje úspěšně k integraci celé komunity. Obrovským přínosem byl příchod SqueakMap, který komukoliv umožňuje snadno publikovat svůj projekt. Díky nástrojům obsaženým přímo ve standardní distribuci Squeaku (Package Loader) pak lze balíčky ze SqueakMap pohodlně stahovat a instalovat do své image.
Dalším projektem, který si okamžitě našel širokou podporu, je verzovací systém Monticello. Ten nejenže poskytuje kvalitní prostředí pro kooperaci více vývojářů, ale představuje obrovský přínos i pro jednotlivé programátory, kteří tak získají snadno použitelný nástroj pro správu svého kódu včetně tvorby komprimovaných zdrojových balíčků s řešením závislostí.
Kromě vývoje samotného prostředí se věnuje také nemalá pozornost provázanosti se stávajícími systémy. Především pak s toolkity pro tvorbu uživatelských rozhraní, jako jsou Gtk a wxWidgets. Bohužel se zatím nejedná o platformně nezávislá komplexní řešení, ale vyvíjejí se rychle a použitelná již jsou.
Ani integrace např. s .Net Frameworkem není problém. Od počátku byl kladen velký důraz na multimediální možnosti Squeaku. Díky tomu obsahuje např. zabudovanou podporu FFT přímo ve virtuálním stroji apod. Ani 3D grafika nezůstává pozadu a uzavřená skupina vývojářů dokonce již delší dobu intenzivně pracuje na projektu Croquet, což je plně trojrozměrné víceuživatelské pracovní prostředí založené na Squeaku. Našince jistě potěší, že jednotliví uživatelé jsou v něm primárně zobrazeni jako tučňáci.
FFT – nářek nad Hektorovou smrtí 
Croquet – Anička v říši divů
Momentálně se usilovně pracuje na novém formátu image založeném na 64bitové architektuře, který by měl být uveden v brzké době s verzí Squeaku 4.0. Vývoj rovněž probíhá na variantách virtuálních strojů s JIT kompilací, podporou víceprocesorových systémů, modularizací image a celou řadou dalších technologií, takže je na co se těšit.
I přes doposud nepříliš velkou uživatelskou základnu probíhá vývoj Squeaku díky jeho brutální otevřenosti velmi rychle a toto tempo se stále zvětšuje, takže tomuto systému rozhodně nehrozí úpadek.
Samozřejmě i Squeak se potýká se stejnými problémy jako většina otevřených projektů podobného rozsahu. Řada věcí není dokončena a u některých vývoj ustrnul úplně. Jediným lékem je dostatečně motivovaná široká základna vývojářů. V tomto směru není, myslím, optimismus zcela nemístný.
Smalltalk je jazyk z dnešního pohledu velmi starý a do značné míry stabilizovaný. Má i svoji ANSI normu. Té Squeak až na pár detailů týkajících se chování některých knihovních metod řešitelných ANSIfikačními balíčky vyhovuje. Při vývoji jeho virtuálního stroje byl nekompromisně dodržován požadavek, aby nové verze byly schopny pracovat se starými imagemi. I v nejnovějších vydáních VM si tedy můžete spustit bez problémů první image. S další verzí tato vlastnost ovšem už možná zachována nebude. Přestože se autoři změnám v jazyce nebrání, zatím se neukázalo, že by byly zapotřebí. Pokud však k nějakým v budoucnu dojde, dá se spíše očekávat zjednodušování.
Proč Smalltalk?
I have found that humans often use smalltalk during awkward moments.
Data
Samotná IBM se snaží prezentovat Smalltalk jako prostředí pro vývoj robustních client/server aplikací na bázi objektově orientovaného modelu. Squeak se pak snaží posunout jeho využití blíže do oblastí, kde se dnes prosazuje Java, tedy k internetovým aplikacím. Smalltalk již dávno ukázal svoje kvality na poli vývoje komplexních informačních systémů. Bohužel se v minulosti vzhledem k ceně a z důvodu obav z výkonnostních problémů nikdy šířeji neuplatnil při vývoji desktopových aplikací (i když např. první verze VisualAge for Java byly napsány ve Smalltalku). Smalltalk dokáže nabídnout neocenitelné služby při tvorbě in-house řešení a v nasazeních, kde je nutné velmi často přistupovat k zásadním modifikacím stávajícího funkčního systému.
Deliver yesterday, code today, think tomorrow.
Jako ryba ve vodě se pak Smalltalk cítí ve vývojové fázi prototypování. Kód v něm napsaný má poměrně malou hodnotu a obrovskou znovupoužitelnost. Bez problémů se v něm dá uplatnit brutální refactoring až na úrovni struktury systému s tak malým počtem zásahů do stávajícího kódu, že těžko hledá konkurenci. V dnešní době, kdy rozhodujícím faktorem ceny nabízeného řešení je často doba vývoje a zákazníci neotálejí modifikovat své požadavky i v pozdních fázích vývojového cyklu, je tato vlastnost k nezaplacení.
To, že při tvorbě smalltalkovských programů dochází k splývání několika fází vývoje, vede k podstatně rychlejší produkci funkčních řešení. Pokud nehrozí, že si pod sebou uřežete nějakou důležitou větev, můžete bez obav vytvářet a modifikovat vyvíjenou aplikaci přímo za běhu a okamžitě testovat dopad provedených změn. Není vůbec náhoda, že se metodika extrémního programování vyvinula na smalltalkovských systémech a přináší na nich také nejpřesvědčivější výsledky.
It had a damn good IDE before the term „IDE“ even existed.
Vývojová prostředí Smalltalku patří mezi to nejlepší, co lze na současném trhu vidět. Díky celé jeho architektuře se může i Squeak o velikosti několika málo megabajtů co do komfortu práce srovnávat s nejkvalitnějšími vývojovými prostředími současnosti. Integrace jazyka do prostředí je nezpochybnitelný trend a třeba C# je pro větší programy bez obalujícího vývojového prostředí už takřka nepoužitelný.
Jediný vážnější problém představuje dokumentace. Na druhou stranu je nutno podotknout, že problémy s ní se týkají především začátečníků. V okamžiku, kdy vývojář nabere dostatek zkušeností a naučí se Smalltalk efektivně využívat a orientovat se v něm, pochopí, proč je jí v celém systému tak málo. Je totiž poměrně málo třeba. Struktura smalltakovských zdrojových textů, čitelnost jazyka, na kterou byl při jeho návrhu brán velký zřetel, a vlastně celá architektura zapříčiňuje, že ve většině případů se jeden krátký komentář u metody, pár slov ke třídě jako celku a vhodná organizace metod naprosto dostačující. Zkrátka při hledání řešení nějakého problému nejdete a nezačnete se probírat dokumentací, ale přímo si probrouzdáte image, což bývá často dokonce efektivnější. S trochou nadsázky lze říct, že pro projekty, jako je Squeak, je tento systém nejvhodnější, protože nejaktuálnější dokumentace je žádná dokumentace.
I never make stupid mistakes. Only very, very clever ones.
Dr Who
Společně s metodikami extrémního programování jdou ruku v ruce i automatizované metody testování softwaru. K použití se nabízí tzv. SUnit společně s obslužnými nástroji. Praxe samozřejmě nevypadá tak, že bychom psali pro každou třídu hned třídu pro její testování, ale pro kritické squeakovské projekty začíná být pomalu pravidlem, že k nim jsou automatizované testy přikládány, aby každý, kdo se rozhodne provádět modifikace (nejen) v těchto projektech, mohl snadno prověřit, zda nemají negativní dopad na stávající funkčnost. Tento trend je zřejmý na první pohled a nelze jej než uvítat.
Life would be so much easier if we could just see the source code.
Smalltalk je pro otevřený a svobodný software mimořádně vhodný jazyk. V době jeho vzniku mu byla jeho otevřenost spíše na škodu, nicméně dnes z ní může vytěžit maximum jazyk, vývojáři i uživatelé. Smalltalk nedává svým uživatelům k dispozici pouze jakýsi virtuální pocit svobody z toho, že k programům mají přiložen i zdrojový kód. V praxi jsou lidé u větších projektů už jen zřídka ochotni prohlížet, studovat, modifikovat a znovu překládat zdrojové kódy. Díky tomu je svobodný software často degradován na programy zadarmo, což neprospívá ani trhu, ani vývojářům a v důsledku ani uživatelům. Smalltalk tak může pomoci ospravedlnit svobodnému softwaru nárok na existenci.
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.
Alan Kay
O kvalitách Smalltalku jako jazyka není pochyb. Přestože se nejedná o nejčistší možný objektově orientovaný jazyk a některé věci mu lze právem vytknout, má vývojářům rozhodně co nabídnout. Síla Smalltalku spočívá v tom, že v sobě slučuje několik nekompromisních přístupů, které se samy o sobě mohou jevit jako omezující, ale jejich vzájemnou kombinací vzniká úžasný funkční systém s řadou nových zajímavých vlastností.
V některých situacích, především u projektů o velikosti několika set tisíc řádků, na nichž pracuje mnoho vývojářů, může být jeho volnost naškodu. Například pokud nejsou voleny názvy parametrů metod dostatečně vhodně tak, aby z nich bylo patrné, jaké typy objektů vyžadují, dohledávání těchto informací zbytečně zdržuje. V podobných případech je vhodné dbát na dodržování jmenných a dokumentačních konvencí. To by ovšem měla být samozřejmost nejen u Smalltalku.
Java: the elegant simplicity of C++ and the blazing speed of Smalltalk.
Jan Steinman
Nesporně zajímavým fenoménem je averze velké části smalltalkovské komunity k některým jiným jazykům a k Javě především. Já ji zprvu vůbec nechápal a považoval jsem ji za zbytečnou s tím, že Smalltalk jenom poškozuje. Ať se to někomu nemusí líbit, ať tak či onak, vždycky vyhrává ten nejlepší. Vždycky. Nemusí se jednat o nejvyspělejší řešení, ale vždy je to řešení, které dokázalo nabídnout nebo vnutit něco víc.
V tomto případě si nemyslím, že vítězem bude Java. A dost možná to nebude ani Smalltalk. Java byla od svého vzniku všeobecně přijímána poměrně chladně a celkově přinesla z mnoha důvodů spíše zklamání. Co se týče návrhu jazyka, je to nevzhledný splácaný paskvil bez nároku na dlouhodobou existenci, jakých už svět pamatuje plno. Je to jazyk vytvořený pro aktuální potřeby trhu, což s sebou přináší kompromisy, které ji sice pomáhají prodat, ale z dlouhodobého hlediska předznamenávají neodvratný konec v propadlišti dějin.
Java není jediný jazyk vyvíjený v polovině devadesátých let ve společnosti Sun, který čerpá ze smalltalkovských konceptů. Dalším je jazyk Self, který představuje její naprostý protipól. V nejednom ohledu se před ním musí sklonit i Smalltalk. Jediné, co Java ze Selfu dokázala využít, je technologie HotSpot. Už když dělala první krůčky, vyvolávala otázky, zda vůbec chceme a potřebujeme další jazyk založený na C++. Pokud se dnes někdo škodolibě zeptá, proč raději autoři Oaku (původní označení Javy) nesáhli po smalltalkovském systému, je odpověď jednoduchá. Chtěli, ale nedohodli se s firmou ParcPlace Systems na pro ně přijatelné ceně a raději zvolili vlastní řešení. To bylo možná pro jejich potřeby vhodnější, neboť vytvářeli jazyk pro programování mobilních zařízení. Otázkou je, jestli je rozumné stavět informační systémy a náročná enterprise řešení na něčem, co vzniklo pro naprosto jiné účely. Jenom proto, že se mateřská firma rozhodla dobýt další segment trhu?
Javě se nepodařilo obsadit oblast desktopových aplikací a nástup platformy .Net pro ni znamenal tvrdou ránu, ze které se pravděpodobně nikdy nevzpamatuje. Minimálně na jedné nejpoužívanější platformě získala silného konkurenta, který, když už nic jiného, nabízí navíc alespoň širší spektrum jazyků. Ani v oblasti svobodného softwaru, kde je vítána její avizovaná platformní nezávislost, se nakonec nesetkala s bouřlivým nadšením.
Studie tvrdící, že systémy založené na J2EE v průměru jeden den v týdnu nefungují, moc velké ovace také nevyvolávají. Java svoji příležitost stát se hlavní vývojovou platformou již propásla a nyní ji bude čekat už jen dlouhý boj o přežití.
Odpověď na otázku, proč používat Smalltalk, samozřejmě neleží v kritice Javy, C# či libovolného jiného jazyka. Tento seriál snad poskytl dostatek materiálu k získání alespoň základní představy o principech, výhodách a nevýhodách Smalltalku. Každý se jistě sám rozhodne, jestli se jedná o technologii, která si zaslouží jeho pozornost.
