ST jako jazyk je jistě super. Ale asi je problém udělat nativní GUI (v Ruby/Pythonu přes Gtk atd), místo toho Squeak používá svoje widgety. A hlavně mi vadi filozofie tvorby aplikaci - na začátku mám celý svět ST, třeba Squeak, který naučím novou funkcionalitu. Jenže pak to musím distribuovat celé, vyhodit třídy, které nepoužívám není jednoduché. Proto se to za ty leta letoucí nikde neprosadilo.
Naproti tomu Ruby/Python jsou tvrdě pragmatické a to je jejich síla.
Smalltalk není jen Squeak a drtivá většina současných implementací Smalltalku nativní widgety používá. Nicméně i Squeak dnes nativní GUI zvládá (http://www.wxsqueak.org/). Na druhou stranu má klasický smalltalkovský přístup k uživatelskému rozhraní celou řadu výhod a naprostá nezávislost na hostitelském systému je jen jedna z nich.
Inkrementální explorativní prostředí Smalltalku je jeho největší předností. S výslednou distribucí hotových aplikací není situace tak jednoznačná, jak by se mohlo na první pohled zdát. Stačí se podívat na Lupu na nedávný článek popisující peripetie s pořizováním elektronického podpisu u České pošty:
"Aplikace pro offline generování certifikátu má 21 MB a je zatím k dispozici pouze pro Windows. Podle často kladených dotazů ale bude časem i pro Linux, MacOS a dokonce i Solaris. 21 MB mě sice nevadí, ale pro modemisty je to prakticky nedosažitelný objem dat. Samotný instalátor se ukázal být ve skutečnosti samorozbalovacím archivem. Nabídne rozbalení do kořenové složky disku a tím jeho funkce končí. Bohužel se ovšem nerozbalí aplikace samotná, ale další instalátor. Navíc se ani automaticky nespustí. Na graficky vydařeném instalátoru mě zaujalo už jen požadované místo na disku 50 MB. Pokud jste očekávali, že zmíněných 50MB obsahuje videoprůvodce generováním certifikátu v DVD kvalitě, zklamu vás. Namísto toho se mi na počítač nainstaloval v pořadí již třetí Java Runtime Environment."
To samozřejmě není chyba přímo Javy, ale o lecčems to také svědčí.
Princip obrazů virtuální paměti je, dle mého názoru, pragmatičtější, ale jeho síla vynikne až u větších a složitějších aplikací.
Příklad. Dnes jsem v jednom informačním systému dělal poměrně zásadní strukturální změny v implementaci vazby závislostí na datový model. Vypadá to asi tak, že na serveru běží v pozadí produkční image a samotné úpravy probíhají na vývojové image. Určíte si, že od daného okamžiku se mají veškeré změny ve zdrojových kódech zaznamenávat, pak se vesele hrabete ve vývojové image, okamžitě změny prověřujete na testovacích datech a ve chvíli, kdy jste hotov, zaznamenané změny exportujete, přičemž je můžete pročistit, doplnit nějakým kódem provádějícím třeba nezbytné konverze stávajících dat apod. Tyto změny pak do běžícího systému za provozu nahrajete. Pokud se dodatečně objeví nějaké problémy, můžete se třeba přes VNC klienta připojit na běžící image (VNC server může být přímo součástí image a není potřeba od hostitelského systému žádná podpora) a tam se v ní trochu prohrabat (pomocí všech vývojových nástrojů a v grafickém prostředí) a okamžitě provést opravu. Pokud je to drobnost, může server pokračovat v procesu generování téže stránky, ve které k chybě došlo, takže pro obsluhu to může vypadat jen jako když se na chvíli nahrávání stránky zasekne. Pokud narazíte na problém větší, prostě si můžete image systému uložit i uprostřed ladění a později někde jinde a třeba i na jiném operačním systému práci dokončit.
Já nepochybuji o tom, že to má své výhody. Někdy třeba i zásadní. Ale fakt je tam, že na mém Windows ani Linux "boxu" (co to ti amici zase vymysleli :-) neběží jediný soft ve ST. Kdysi tu byl seriál o nějakém ST frameworku pro web - ale vsadím se, že na Pythonu nebo Ruby běží řádově víc webů. Zkrátka ty komplikace jsou značné.
ČLÁNKY DO MAILU