Pharo 4.0

Vyšlo Pharo 4.0 (otevřená implementace Smalltalku). Přináší nové vývojářské nástroje pro zkoumání objektů a zdrojových kódů, zlepšeny byly reflektivní vlastnosti instančních proměnných, přibyl tmavý motiv uživatelského rozhraní a mnoho dalšího.

16.4.2015 14:29 | Pavel Křivánek | Nová verze

Komentáře

[Bystroushaak]

Vypadá to sexy :)

Teď ještě aby vyšla ta slibovaná nová verze Pharo by example, protože ta stará je beznadějně outdated.

[xkucf03]

Podle toho obrázku to vypadá, jako kdyby tam naportovali Eclipse

[yoli]

S eklipsom to ma spolocne len ikonky

[kouzer]

Koukám, že to používají v ČSOB.

http://pharo.org/success

[xkucf03]

Jak se programy ve Smalltalku vlastně verzují?

[Pavel Křivánek]

Pharo obsahuje vlastní verzovací/balíčkovací systém jménem Monticello. Ten těží do značné míry z toho, že pro Smalltalk je program sada provázaných objektů a ne jen sáhodlouhý kus textu (textová forma je jen jedna z možností a slouží především pro přenos zdrojových kódů). Je tedy docela snadné porovnávat zdrojové kódy na úrovni jednotlivých metod bez složitých analýz apod. Jedna z možností jak serializovat zdrojové kódy v Monticellu je si je nechat ukládat v adresářové struktury vhodné pro běžné verzování Gitem (FileTee). Každá metoda je pak uložena ve vlastním souboru (viz zdrojové kódy pro Pharo samotné). Je k dispozici rozšíření Monticella, které se stará o přímou spolupráci s Gitem, aby běžné commitování bylo co nejpohodlnější. Počítá se s další lepší integrací Gitu přímo v základním Pharu (např. začleněním gitlib do standardní VM).

[luky]

Mne sprava kodu prijde jako nejvetsi pakarna ve svete smalltalku - v podstate je to nepouzitelne na vetsi projekt. Rad bych vedel, jak si predstavuji, ze v tom bude spolupracovat i treba uz jen nekolik desitek lidi, na projektu, ktery ma vice vetvi. V podstate se to cely musi ohackovat, aby se daly kody verzovat ve forme textu a pouzivat nastroje na sledovani problemu, review, mergovani, internich procesu vyvoje a CI, protoze nativni bud uplne chybi a nebo jsou na urovni kulickoveho pocitadla.

[OldFrog {Ondra Nemecek}]

Pokud by se svět smalltalku (třeba Pharo) trochu přizpůsobil zbytku světa, má podle mě slušnou šanci, protože ledy tají a do popředí se dostávají různé progresivní směry (jazyky nad jvm, měnící se status javascriptu, různé transpilery apod.) Bohužel nezvyklé gui a styl práce musí většinu zájemců odradit. Sem asi patří i to verzování...

Možná bych se zeptal pana Křivánka, jestli existuje nějaká snaha tohle změnit? Existují nějaké reálné aplikace pro Pharo, které by si šlo vyzkoušet a existuje nějaký návod, který popisujíce zvyklosti a obyčeje prostředí?

[Pavel Křivánek]

Reálných samostatných aplikací, které by využívaly přímo Morphic, je velmi málo. Většina projektů je zaměřena na web. Ale zmínil bych např. http://www.drgeo.eu/ nebo http://www.phratch.com/. Pro aplikace se standardním GUI se dá použít třeba Phobos využívající XULRunner (screenshoty).

Snahy o sblížení se s okolním světem a zpřístupnění Phara nováčkům samozřejmě jsou. Viz integrace Gitu, předpřipravené konfigurace projektů, Pharo nově nabízí image bez GUI atd. Ale především na dokumentační frontě je potřeba pořádná ofenziva.

[OldFrog {Ondra Nemecek}]

Díky za zajímavé odkazy. Jak jsou na tom komerční smalltalky? Existuje něco vyspělého a používaného?

[Pavel Křivánek]

Příloha:

• Snímek obrazovky - 19.4.2015 - 22:18:26.png (142833 bytů)

Jednoznačně zkuste VisualWorks (viz screenshot). Za pozornost určitě stojí i Smalltalk/X, který má výbornou provázanost s C a spoustu zajímavých vlastností. Svět Smalltalku se netočí jen kolem Phara.

[Bystroushaak]

Když už tu vedeme lehce offtopic diskuzi, jak je na tom pharo co se týče propojení s pythonem? Dá se nějak pracovat z phara s kódem v pythonu, či naopak?

[Pavel Křivánek]

Dá, jeden Řek tak třeba ovládá z Phara Blender: https://www.youtube.com/watch?t=11&v=yIE1LGjUDDA

[Bystroushaak]

Tak jsem našel pyAtlas, který nějak souvisí s pyEphestos. Ten kód je docela slabota, dokáži si představit podstatně vyšší úroveň propojení, než tohle. Asi se na to budu muset podívat, až se naučím pharo :)

Related:

• invoking python from pharo
• Calling Python from Pharo

[Radek Miček]

V podstate se to cely musi ohackovat, aby se daly kody verzovat ve forme textu

Proč myslíte, že je dobrý nápad verzovat na úrovni textu?

jsou na urovni kulickoveho pocitadla.

A jaké nástroje jsou na vyšší úrovni? Právě problém je v tom, že většina nástrojů funguje pouze na úrovni textu – nerozpoznají například ekvivalentní kód (ani v triviálních situacích), nejsou schopny změny inteligentně prezentovat (například při přejmenování proměnné musíte revidovat každý řádek, kde se jméno změnilo), nejsou schopny inteligentě mergovat (například stačí ve dvou větvích přejmenovat věci blízko sebe a dostanete zbytečné konflikty nebo naopak, když změny nejsou blízko sebe a jsou konfliktní, tak konflikt nedostanete).

[OldFrog {Ondra Nemecek}]

Podle mě Luky myslí právě to, že správa textového kódu je všeobecně známá a zavedená a proto pro ní existuje mnoho nástrojů na vše.

I zde se ukazuje, že by prospěl nějaký popis „jak se to dělá ve smalltalku“.

[Radek Miček]

že správa textového kódu je všeobecně známá a zavedená a proto pro ní existuje mnoho nástrojů na vše.

Právě ty nástroje na správu textu nejsou většinou vhodné na správu programů – mnohem raději bych ukládal informaci, která říká, že se proměnná v nějaké funkci s nějakým typem přejmenovala, než informaci, že se změnilo deset písmen na 5., 7., a 12. řádku v nějakém souboru.

[OldFrog {Ondra Nemecek}]

Ano, tomu rozumím, ale při reálné práci potřebujete něco, co každý používá a co je považováno za standard. Mluvím stále o tom, že Smalltalk má nedostačující napojení na okolní svět - je to prostě svět sám pro sebe.

[Radek Miček]

při reálné práci potřebujete něco, co každý používá a co je považováno za standard

Proč?

Smalltalk má nedostačující napojení na okolní svět - je to prostě svět sám pro sebe.

A potřebuje napojení na okolní svět? Co vám brání udělat lepší nástroje, než používá okolní svět? To, že nějaký nástroj nebo postup používá většina lidí, ještě neznamená, že je to dobrá volba.

[luky]

A potřebuje napojení na okolní svět? Co vám brání udělat lepší nástroje, než používá okolní svět?

Cas, vetsinou je totiz levnejsi si ten nastroj koupit a venovat se vlastnimu projektu.

[Radek Miček]

Myslíte, že je to většinou levnější i z dlouhodobého hlediska?

Kvůli ne plně vyhovujícím nástrojům od třetích stran například strávíte nad revizemi kódu více času, než je třeba, a více chyb zůstane neodhaleno. Nebo strávíte více času mergováním – jednak řešíte zbytečné konflikty a algoritmy pro mergování v Gitu nebo Mercurialu nejsou plně vyhovující (např. pro criss-cross merge). Všeobecně používané nástroje pak mohou mít funkcionalitu, kterou nepotřebujete nebo dokonce nechcete. Nakonec se tedy možná psaní vlastních nástrojů nakonec stejně nevyhnete.

[OldFrog {Ondra Nemecek}]

Pokud to nebude napojené, nedostane se to mezi lidi a bude to věčný experiment ve stylu GNU Hurd. Čím pokrokovější myšlenky projekt obsahuje, tím lépe musí být přístupný současné praxi.

[luky]

Presne na todle se ale mohou pouzit semanticke patche, opensource spatch je uz alespon 5 let velmi dobre pouzitelny.

[xkucf03]

Což o to, tohle všechno by se mi líbilo možná je tohle příští generace verzovacích systémů, ale není to tak jednoduché:

• Většinou je potřeba verzovat i jiné věci než zdrojový kód v určitém jazyce (dokumentace, diagramy, konfigurace atd.), takže podpora klasického textového verzování je stejně potřeba. A v rámci jednoho projektu chci používat jeden verzovací systém a mít na jednom místě přehled, co se v projektu mění.
• Muselo by se verzovat na úrovni syntaktického stromu a verzovací systém by musel rozumět syntaxi mnoha různých jazyků.

[tacoberu]

• Muselo by se verzovat na úrovni syntaktického stromu a verzovací systém by musel rozumět syntaxi mnoha různých jazyků.

Což by nemusel být žádný problém. Když to dokáže kdejaký editor zvýrazňující syntax...

[Radek Miček]

Když to dokáže kdejaký editor zvýrazňující syntax...

Často to ty editory nedělají úplně správně. Kromě toho u některých jazyků jde měnit syntax, což editory většinou vůbec nezvládají.

Další problémy by byly s tím, když například používáte novou verzi jazyka nebo nějaký fork jazyka, který má jinou syntax.

Pro zajímavější funkcionalitu by byla potřeba i sémantika.

Nicméně Pharo je uzavřený svět a Smalltalk není tak komplikovaný jazyk (je to pravda?), takže by nemuselo být složité udělat lepší nástroje?

[xkucf03]

Když se nepovede zvýraznění syntaxe, tak to až takové tragédie není, máš to jen špatně obarvené, ale pokud pomocí toho chceš verzovat, musí to být 100% spolehlivé. Aplikace patche musí vést za všech okolností na stejný výsledek.

[tacoberu]

Tak to máš asi pravdu. Jenže na druhou stranu, to se vážně nechceme někam pohnout?

[xkucf03]

Což o to, já bych i chtěl, ostatně nemyslím si, že by současné DVCS (Mercurial, Git, Bazaar…) byly nějaké finální stádium – dokonalost – a nečeká nás nic dalšího. Nevím, jestli budeme mít někdy plně sémantické patche, ale možná by pro začátek šlo ke klasickému řádkovému patchi přidat metadata typu: „přejmenoval jsem proměnnou“, „přesunul jsem metodu na jiné místo bez vlivu na funkčnost“, „změnil jsem předka třídy“. Časem se ten formát „prostý text“ možná dostane na úroveň jiných formátů (Java, C++, SQL, Smalltalk…) a bude jen zvláštním případem – strom bude plochý a uzlem bude jeden řádek, možná slovo.

Nicméně je to běh na dlouhou trať a vyžaduje to, aby verzovací systém perfektně rozuměl těm jazykům, měl modul pro každý z nich a podporoval aktuální verzi těch jazyků. Zároveň potřebuješ i podporu IDE a nemůžeš pak používat nic jiného, protože je potřeba, aby editor věděl, co děláš a průběžně zaznamenával tvoji činnost, ne jen zpětně porovnal původní a výsledný stav.

A má to širší souvislosti – když už budeš mít nástroje (ne jen kompilátor), které tak dobře rozumí danému jazyku, nemusíš programovat jen psaním kódu, můžeš ten program upravovat víc vizuálně, v nějakém WYSIWYM editoru, mít graf toho programu, který neslouží jen jako needitovatelná dokumentace, ale můžeš do něj sáhnout, něco někam přesunout, přidat vazbu, natáhnout šipku z jedné metody do druhé… Spíš tohle bude předcházet těm sémantickým patchům – protože pak (až nebudeš editovat jen text), je budeš opravdu potřebovat (informace, že se změnil řádek 123 ti nic moc neřekne). To se týká i takových kancelářských textových editorů, grafických editorů, střihu videa atd.

[tacoberu]

Já bych to viděl přesně naopak. Nejdřív se musí verzovací systém naučit sémantiku, a pak musí být schopni rozumět textovým patchům.

Konkrétní příklad:

Dělám na nástroji, který verzuje databázové schema. Každý commit v textovém souboru je řada nějakých SQL příkazů. Požadavek zní, aby když udělám nějakou ruční změnu ve schematu databáze, tak aby se mi pro tuto změnu automaticky vygeneroval patřičný patch. A to třeba i takový, aby se mi ve správném pořadí mazali tabulky, které na sebe mají závislosti. Takže ten nástroj musí mít dost inteligence, aby toto všechno byl schopen zpracovat a vygenerovat, ale pak to stejně uloží do textového patche.

Asi takhle bych si to představoval i u Java, C, ... Bude to chtít odvahu, ale je to krásný nový svět.

[xkucf03]

Pokud je z toho ve výsledku zase textový patch, tak je to nástroj nezávislý na verzovacím systému a v pohodě jde používat ty dnešní (Mercurial, Git, Bazaar…). Takových nástrojů je už teď celkem dost – různá IDE, která umí refaktorovat kód nebo hledat výskyty využití (kde se skutečně daná metoda/funkce volá, ne jen nějaké primitivní vyhledávání textů), nebo různé parsery, generátory, transformátory, transpilery… nebo analyzátory kódu (často integrovaná do IDE), které ti najdou chyby, podezřelá místa nebo dají návrhy na optimalizaci.

[Pavel Křivánek]

Příloha:

• PharoScreenshot.1.png (61758 bytů)

Tady bych jako příklad použil samotné Pharo. Máte rozepsán vlastní projekt a najednou narazíte na nějakou snadno opravitelnou chybu základním systému. Prostě ji hned opravíte, napíšete krátký záznam do issue trackeru a se získaným číslem problému commitnete vybrané změny ze své image do inboxu. Záznam v issue trackeru označíte jako uzavřený, načež na něj za chvíli vlítne automat, který upravené verze balíčků zkusí nahrát a prohnat testy. Když to projde, označí se oprava jako vhodná pro lidské zhodnocení. Balíčky z několika uzavřených problémů integrátor zmerguje a vytvoří tak novou verzi Phara, kterou následně automaticky prožene CI dalšími důkladnými testy a je-li vše v pořádku, publikuje. Git v tom v současné chvíli hraje podružnou roli archivace výsledků. Úplně nepoužitelné to celé není. Přikládám screenshot Monticella při porovnání dvou balíčků.

Nicméně příští verze Phara se má na Git zaměřit. Důvody jsou pěkně sepsány zde: http://smallworks.eu/web/blog/2014-01-16-Why-Im-using-git.

[luky]

JJ, todle je v pohode u mensiho projektu. U neceho vetsiho se chyba bude muset nahlasit zakaznikum, polovina z nich ten fix odmitne, protoze je chyba neovlivnuje a alespon jeden to bude chtit upravit uplne jinak, takze nakonec skoncite u spousty vetvi, mezi kterejma budete ruzne slucovat ruzne zaplaty. Na kazde vetvi se bude delat rozdilne testovani, ktere samozrejme zavisi jeste na provedene zmene, takze se stava, ze se musi urgentne opravit neco, nez dobehnou testy predchoziho buildu a musi se vetvit znova pred predchozi zmenou. Pokud si na spravu toho bordelu neporidite nejaky nastroj, tak po mesici pojedete do cvokarny. A vsechny nastroje, ktere za neco stoji, pracuji s textovymi zdrojaky.

[xkucf03]

U neceho vetsiho se chyba bude muset nahlasit zakaznikum, polovina z nich ten fix odmitne, protoze je chyba neovlivnuje a alespon jeden to bude chtit upravit uplne jinak, takze nakonec skoncite u spousty vetvi, mezi kterejma budete ruzne slucovat ruzne zaplaty.

Když se takhle dodavatel chová, tak špatně skončí bez ohledu na použitou technologii.

[luky]

A jak se tedy ma chovat? Poslat zakazniky do haje a vyrabet jen pro sebe?

[OldFrog {Ondra Nemecek}]

Neukazuje to na špatnou architekturu aplikace, když je potřeba pro každého zákazníka jedna větev?

Viděl bych to tak, že by to chtělo mít sdílené jádro + implementaci specifickou pro každého zákazníka. Například.

[xkucf03]

Neukazuje to na špatnou architekturu aplikace, když je potřeba pro každého zákazníka jedna větev?

Tak nějak…

Viděl bych to tak, že by to chtělo mít sdílené jádro + implementaci specifickou pro každého zákazníka. Například.

To je jedna z možností, vytvořit nějaký framework a pro jednotlivé zákazníky dodávat jeho aplikaci, parametrizaci (součástí níž je i spustitelný kód). Další z možností je mít společný základ, který je sám o sobě spustitelný a do něj přidávat moduly – s tím, že některé moduly budou pro všechny a jiné pro konkrétní zákazníky. Tenhle přístup je mi bližší, ale i ten první dává smysl.

[Pavel Křivánek]

Bohužel žijeme v reálném světě a oni tu aplikaci mají a jen tak ji asi přepisovat nebudou. Doporučil bych zdražit podporu těm, kteří nebudou mít instalovánu aktuální standardní verzi (raději to prezentovat jako slevu pro ty, co ji mít budou) a co se týče rozdílných požadavků na opravy chyb, to ať se zákazníky proberou dopředu a najdou vhodné (třeba parametrizované) řešení použitelné pro všechny.

[luky]

Neukazuje to na špatnou architekturu aplikace, když je potřeba pro každého zákazníka jedna větev?

Tak nějak…

Viděl bych to tak, že by to chtělo mít sdílené jádro + implementaci specifickou pro každého zákazníka. Například.

To je jedna z možností, vytvořit nějaký framework a pro jednotlivé zákazníky dodávat jeho aplikaci, parametrizaci (součástí níž je i spustitelný kód). Další z možností je mít společný základ, který je sám o sobě spustitelný a do něj přidávat moduly – s tím, že některé moduly budou pro všechny a jiné pro konkrétní zákazníky. Tenhle přístup je mi bližší, ale i ten první dává smysl.

A jak todle vyresi to, ze zakaznik odmitne zaplaty do spolecneho jadra, ktere ho neovlivnuji?

[OldFrog {Ondra Nemecek}]

Pokud zákazník mluví do vnitřností, tak se podílí na vývoji a musí se tomu uzpůsobit smluvní vztahy, aby se dojednaly podmínky schůdné pro všechny. Udržování samostatné větve je dost nákladné - zákazník bude muset nést vyšší náklady. Jinak hrozí, že produkt zanikne a to pak ani zákazník nebude rád (anebo si oddechne a přejde ke konkurenci).

Ale chápu, jak snadno tahle situace vznikne a jak těžko se pak řeší, protože to zákazník bude vždycky vnímat tak, „že to vždycky šlo a najednou je problém“.

[luky]

Zakaznik si to plati a vpodstate jediny duvod, proc by mel souhlasit s opravou, je ekonomicky. Chyba, ktera se v jejich scenari nemuze vyskytnout, jim zpusoby problemy v 0% pripadu a moznost zavleceni chyby opravou je >0% - kazdy racionalne uvazujici clovek takovou opravu odmitne, pokud k ni neni motivovan financne.

[OldFrog {Ondra Nemecek}]

Při rozumné aplikační architektuře mu prostě zmrazíte verzi jádra a custom kód budete vyvíjet proti této zmrazené verzi. Zákazník pak bude omezen co se týče nové funkčnosti, protože nebude moct užívat nové vlastnosti jádra. Je to cena za stabilitu, kterou požaduje. V tomto scénáři nemusíte udržovat samostatnou větev jádra, pouze custom kód.

Pokud by zákazník chtěl novou funkci, která je dostupná v novějším jádru, musí aktualizovat nebo si zaplatit vývoj custom jádra. Pak musí znát reálné náklady na tento vývoj i problémy, které takový vývoj přináší.

A pokud je prioritou spolehlivost, bez důkladných testů to nejde. Což jsou další náklady, se kterými musí být zákazník taky srozuměn.

[luky]

Vsak ja nerikam, ze za to neplati. Pisu jen, ze k tomu, aby takovy vyvoj byl udrzitelny, je potreba mit dobre nastroje na spravu a SmallTalk se svou architekturou od nich odstrihl.

[OldFrog {Ondra Nemecek}]

Tím pádem ovšem nejste asi typický případ a potřebujete robustnější řešení než Pharo nyní nabízí (nedokážu posoudit).

Mimochodem možná by bylo zajímavé, kdybyste napsal vaše zkušenosti z nástrojů a postupů, které používáte a poslal to jako připomínku vývojářům Phara. Vždycky je zajímavé vidět, jaké se vyskytují praktické potřeby.

[xkucf03]

• Zákazník nemá co mluvit do interních technických detailů – pak to není zákazník, ale spoluautor – zákazník má specifikovat požadavky (funkční, výkonnostní…).
• Některé firmy se točí v kruhu: mají nějaké problémy, nízkou kvalitu a morálku, už je jedno, jak to vzniklo → nedaří se jim upgrady, často selhávají → zákazníci se upgradů bojí → tlačí na to, aby se neupgradovalo, aby se oprašovaly prastaré verze, aby se vyvíjelo ve speciálních větvích jen pro ně, některé změny se propagovaly a jiné ne → to zase zpomaluje vývoj, snižuje efektivitu, zanáší nové chyby, demoralizuje vývojáře → upgrady jsou zase problematické… a tak pořád dokola.

[Bystroushaak]

Příloha:

• smalltalk.jpg (185954 bytů)

Tak dneska to konečně přišlo :)

[Pavel Křivánek]

Tomu se říká odhodlání!