Pharo 5.0

Vyšlo Pharo 5.0 (otevřená implementace Smalltalku). Díky vylepšené správě paměti je o 35% rychlejší, používá nový debugger, usnadňuje propojení s externími nativními knihovnami a přináší další tisíce menších změn a oprav.

12.5.2016 19:55 | Pavel Křivánek | Nová verze

Komentáře

[Bystroushaak]

Vypadá skvěle. Je dobré vidět, jak se to rozjelo.

[Bedňa]

Tak ja C++ mohlo byť objektovým programovacím jazykom v novom štandarte.

Stačilo sa držať pravidla, že všetko do niečoho patrí a mali by sme vyriešenú správu pamäti.

Načo pointre a hviezdičkové operátory, načo pointorvá aritmetika kde stále píšeme dookola to isté a vytvárajú sa stále tie isté chyby a namiesto toho to nechať na strane kompilátora o problémoch s detekciou chýb nehovoriac.

A načo main() toto fakt ešte patrí do 21 storočia?

Pharo som skúšal a nieje to tak simple ako propagujú, teda napr. Gambas je dosť v objektoch priamočiarejší, ale zas tá syntax Visual Basicu mi vadí. No ale naimplementovať do toho Python, alebo C++ syntax, tak to by bolo niečo.

[kralyk z abclinuxu]

Stačilo sa držať pravidla, že všetko do niečoho patrí a mali by sme vyriešenú správu pamäti.

Na tom je založen Rust. Tomu já fandím (to je o mě koneckonců známo ), ale je potřeba mít na paměti (no pun intended), že programování to může někdy dost zesložitit, zejména prvnotní návrh, a je spousta situací/use-casů, kdy je GC vhodnější. To musím bohužel uznat, jakkoli mi je koncept GC filosoficky odporný

[Sid]

tak ono by sa to mohlo teraz trocha vylepsit s ich vylepsenym kompilatorom. Zaprve niektore umele obmedzenia sa odstrania a za druhe by to mohlo vylepsit aj hlasky co lezu z borrow checkera, lebo obcas pochopit co presne by chcel je asi ako skumat chybu v argumente template pri C++.

[Bedňa]

Je možné že máš pravdu, čo sa týka tej zložitosti, to by mal riešiť compilátor a nie programátor, teda všeobecne návrh jazyka. Tých frameworkow je na mraky a stále vznikajú nové tak je odkiaľ brať hotové riešenia.

[Bystroushaak]

Pharo som skúšal a nieje to tak simple ako propagujú, teda napr. Gambas je dosť v objektoch priamočiarejší, ale zas tá syntax Visual Basicu mi vadí. No ale naimplementovať do toho Python, alebo C++ syntax, tak to by bolo niečo.

Tohle nemá s Visual Basicem vůbec nic společného.

Nad tím jak by to mohlo vypadat s pythonem jsem uvažoval, dokonce docela dost. Problém je, že python prostě totálně není na něco podobného připravený a celý interpret bys musel kompletně přepsat jen abys získal .. parodii na Smalltalk. Smalltalk je ve skutečnosti dost pokročilý. Sice má triviální syntaxi (podobně jako v lispu je jí fakt minimum), ale co do funkcionality je propracovaný.

Jinak gratuluju k prvnímu odrazu :) Já se takhle odrazil asi 5x, než jsem konečně uznal, že je to co k čemu.

[kralyk z abclinuxu]

Smalltalk je ve skutečnosti dost pokročilý. Sice má triviální syntaxi (podobně jako v lispu je jí fakt minimum), ale co do funkcionality je propracovaný.

Nedávno mi konečně došlo, co mi na lispu tak vadí - je to přesně tahle vlastnost (když pominu nadutost některých proponentů). Na začátku je pěkný návrh - jednoduchý, elegantní a konzistentní systém s pěknými vlastnostmi (alespoň z pohledu CS), nicméně jak směrem 'dolů' (tj. k implementaci) tak 'nahoru' (tj. k programátorovi) z něj plyne o to vyšší komplexita. Dole jsou potřeba velmi složité imeplementace, aby vůbec umožnily jakés-takés fungování onoho elegantního systému. Nahoře zase vzniká nad jednoduchým základem složitý a nepřehledný ekosystém, takže pro praktické programování zdaleka nestačí pouze pochopit onen prvotní návrh.

Když pak někdo poukáže na to, že implementace mají specializovanou podporu pro různé datové typy a jazykové konstrukty, proponenti čistého designu ho odbydou s tím, že to je pouze optimalizace nějaké konkrétní implementace a na eleganci designu to nic nemění, ten by byl platný i bez nich. (Což je sice pravda, ale byl by také nepoužitelný v praxi).

Čili ten jednoduchý, elegantní a konzistentní návrh je v podstatě naprostá iluze.

[Adrin]

Myslím si, že o tom by se dalo asi diskutovat. Směrem dolů k HW půjde o složitější implementaci, ale to je společný "problém" i skriptovacích a jiných vyšších jazyků. Na druhou stranu elegantní syntaxe často znamená i odlehčený interpreter/compiler, takže tady je implementace jednodušší. Vytvořit funkční compiler pro C++ může být stejně tak náročné nebo možná i náročnější než vytvořit virtuální vrstvu pro vyšší programovací jazyk (pokud je návrh té vrstvy elegantní).

Směrem nahoru k programátorovi jde dle mého o výběr mezi svobodou vyjadřování a vyšší kontrolou. Kontrola se ale nikdy nedá zaručit vždy a všude. Z principu nelze pomocí syntaxe zaručit kontrolu návrhu (k tomu mohou pomoci až frameworky) a pak stejně zůstane mnoho mezer, kde lze "prasit". Syntaxe Smalltalku je právě spíše svobodná a znamená to potom dát větší důraz na testování a případně implementovat pokročilý debugger (což Pharo má) a frameworky, které sjednotí styl práce (což má také).

Složitý ekosystém je dle mého reálný nebo potenciální problém všech živě rostoucích platforem bez ohledu na programovací jazyk (zvláště pokud do platformy přispívá řada silných individualit, případně když si platforma sebou táhne historickou zátěž).

[kralyk z abclinuxu]

Souhlasím, že ostatní jazyky tu komplexitu mají taky (nebo i více - C++ je v tomhle ohledu klasický příklad), ale ostatní jazyky si ani typicky na tu jednoduchost / eleganci nehrajou...

[Bystroushaak]

Dole jsou potřeba velmi složité imeplementace, aby vůbec umožnily jakés-takés fungování onoho elegantního systému. Nahoře zase vzniká nad jednoduchým základem složitý a nepřehledný ekosystém, takže pro praktické programování zdaleka nestačí pouze pochopit onen prvotní návrh.

Implementace lispu je naopak velmi jednoduchá (~1000 řádek kódu). Je ale fakt, že jen ta implementace samotná ti většinou nestačí a musíš věnovat podstatnou část naučení se ekosystému lispového kódu, který je nad tím. Ale to platí i v pythonu, který by byl bez standardní knihovny podstatně slabší.

[kralyk z abclinuxu]

Implementace lispu je naopak velmi jednoduchá (~1000 řádek kódu).

Měl jsem pochopitelně na mysli reálně použitelné implementace. Dovolím si odhadovat, výkonnostní parametry 1000-řádkové implementace budou stát za houby. Nejpopulárnější dialekty - tzn. aktuálně afaik Clojure a CL - tak úplně jednoduché implementace nemají.

[Bystroushaak]

Nezapomeň na scheme, to má docela jednoduchý interpretr (záleží tedy na verzi). Pravda, ne zrovna 1000 řádek, ale pořád je to docela malé.

[Bedňa]

Myslel som to inak, ale dík za to uznanie :)

[Bystroushaak]

Jinak pro mě byl silný argument, když jsem pochopil tohle; https://www.youtube.com/watch?v=sIgrZyEzPe4

[Bedňa]

Tá práca s API vyzerá moc luxusne.

[Adrin]

Super. Ještě doplnit podporu 64bit :)

[Pavel Křivánek]

64-bitová verze bude doplněna během léta. Je to jeden z důvodů přechodu na nový paměťový model.

[tukan]

Konečně se něco děje. Taky aby se vrhli na ty thready.

Mohu za sebe doporučit vyzkoušet si StX: (to už je 64bitové .)) https://swing.fit.cvut.cz/projects/stx-jv .

Začal jsem si oprašovat znalosti Smalltalku právě na StX (doplňování kódu, možnost spouštění Java knihoven uvnitř StX, SmallSense.).

Zatím největší nedostatky obecně Smalltalku vidím:

Používání Green threads ve VM - t.j. klasický problém jako u MRI ruby nikomu se nechce do nativních vláken i když v na dnešních 10 jádrových procesorech už je to sakra za potřebí.

Dalším jsou verzovací systémy (StX má Mercurial, někde měl náznak i git(uú). Pharo snad možná bude mít git. Jinak je tam Monticello a je pro vývoj ve více lidech nepoužitelné (stačí se podívat na merge kódu.)

Jinak jsem také velký přívrženec Rust(u) i když jím zatím nevládnu a doufám, že by právě nějaké VM mohla být napsaná v něm. Bylo by to o dost lepší než dnešní jiné možnosti.

Smalltalk is dead. Long live Smalltalk .))

[Bystroushaak]

Dalším jsou verzovací systémy (StX má Mercurial, někde měl náznak i git(uú). Pharo snad možná bude mít git. Jinak je tam Monticello a je pro vývoj ve více lidech nepoužitelné (stačí se podívat na merge kódu.)

Pharo už afaik má podporu gitu nějakou dobu.

Jinak jsem také velký přívrženec Rust(u) i když jím zatím nevládnu a doufám, že by právě nějaké VM mohla být napsaná v něm. Bylo by to o dost lepší než dnešní jiné možnosti.

Proč by to mělo být lepší než smalltalk VM psaný ve smalltalku?

[Jan Vrany]

Proč by to mělo být lepší než smalltalk VM psaný ve smalltalku?

Otazka se da polozit i obracene - proc by VM napsana ve Smalltalku mela byt lepsi nez ta napsana v Rustu? A co vubec znamena lapsi?

Navic, Squeak VM (tedy VM na ktere bezi i Pharo a Cuis) neni psana ve smalltalku, ale ve slangu, coz je limitovana podovmnozina smalltalku. Neco jako Python a RPython, pokud znate PyPy.

[Bystroushaak]

Otazka se da polozit i obracene - proc by VM napsana ve Smalltalku mela byt lepsi nez ta napsana v Rustu? A co vubec znamena lapsi?

Protože nepotřebuješ separátní jazyk se separátníma závislostma, komunitou a ekosystémem, který navíc za pár let může být úplně mrtvý. Já teď čtu historický archiv Self konference za posledních 25 let, tak mi to tak nějak změnilo pohled na moderní trendy.

Navic, Squeak VM (tedy VM na ktere bezi i Pharo a Cuis) neni psana ve smalltalku, ale ve slangu, coz je limitovana podovmnozina smalltalku. Neco jako Python a RPython, pokud znate PyPy.

Znám.

[tukan]

Otazka se da polozit i obracene - proc by VM napsana ve Smalltalku mela byt lepsi nez ta napsana v Rustu? A co vubec znamena lapsi?

Protože nepotřebuješ separátní jazyk se separátníma závislostma, komunitou a ekosystémem, který navíc za pár let může být úplně mrtvý. Já teď čtu historický archiv Self konference za posledních 25 let, tak mi to tak nějak změnilo pohled na moderní trendy.

Právě protože je takový problém psát multithreadové VM, protože je to náročné ty chyby dohledat, chce to jazyk který bude hlídat co nejvíce věcí ohledně možných chyb a zůstane relativně rychlý např. jestli se nezapisuje do paměti, která není jeho atp. To jestli to bude za pár let mrtvé nedokáže předpovědět nikdo, ale ta potřeba kvůli které vznikl Rust (podle tvůrců zoufalí programátoři C++\C), tedy něco co bude relativně rychlé a bude už z návrhu předcházet chybám tu byla a podle mého jen poroste jak složitost systémů bude narůstat. (s nárůstem složitosti bude i složitější chyby dohledat).

[Bystroushaak]

Právě protože je takový problém psát multithreadové VM, protože je to náročné ty chyby dohledat, chce to jazyk který bude hlídat co nejvíce věcí ohledně možných chyb a zůstane relativně rychlý např. jestli se nezapisuje do paměti, která není jeho atp.

S tím souhlasím, ale myslím si, že se to pořád dá psát ve Smalltalku (resp. slangu / whatever).

potřeba kvůli které vznikl Rust (podle tvůrců zoufalí programátoři C++\C), tedy něco co bude relativně rychlé a bude už z návrhu předcházet chybám tu byla a podle mého jen poroste jak složitost systémů bude narůstat. (s nárůstem složitosti bude i složitější chyby dohledat).

Potřeba určitě, ale o tohle místo teď soutěží hned několik jazyků a celkem jisté je, že jak už to tak historicky bývá, „vítězem“ bude jeden. Že to bude zrovna Rust se mi nezdá samozřejmé.

[kralyk z abclinuxu]

Potřeba určitě, ale o tohle místo teď soutěží hned několik jazyků a celkem jisté je, že jak už to tak historicky bývá, „vítězem“ bude jeden. Že to bude zrovna Rust se mi nezdá samozřejmé.

Souhlasím, zajímalo by mě ale, jaké jsou ty alternativy s nějakou třeba podobně pěknou podporou pro bezpečný přístup ke sdíleným prostředkům...

[Bystroushaak]

Samozřejmě, že to nejsou 100% alternativy Rustu. Jsou to alternativy místa, které zabíralo C++. Viděl bych to na souboj D, Go a Rustu, možná ještě nějakého nového standardu C++.

[tukan]

Go má výhodu, že tu vlastně bylo dříve a Rust není ještě usídlen. Podle všeho návrh Rustu je lepší pro vývoj aplikace co člověk chce mít pod kontrolou (nebo třeba použít GC a nestarat se). D vůbec neznám k tomu se nemohu vyjádřit.

Ne vždy vyhrává lepší, protože lepší usne často na vavřínech (viz. Smalltalk), každopádně si myslím, že se Rust objevil v čas a jeho čas přijde. To jestli se uchytí pevně nebo vymizí samozřejmě netuším. To bude hodně záležet na komunitě jejímu přístupu.

[Bystroushaak]

Go má výhodu, že tu vlastně bylo dříve a Rust není ještě usídlen.

Go má hlavní výhodu v tom, že za ním stojí Google a taky ho protlačuje. Oproti tomu Mozilla je v poslední době skoro zárukou toho, že se z toho časem vyklube fail (nic proti jazyku jako takovému).

To bude hodně záležet na komunitě jejímu přístupu.

To je pravda. Komunita lidí s potřebou se mi právě teď zdá rozštěpená a teprve budoucnost ukáže, kam se převáží vážky většiny. Protože v konečném důsledku je to právě komunita, která zajišťuje, že jazyk je co k čemu.

[kralyk z abclinuxu]

D už to má imho za sebou. Go naproti tomu vypadá dost úspěšně. Ale má trochu jiné zaměření... Rust míří na segment v současné době zabraný C/C++, zatímco Go spíše IMHO na Javu, .NET apod.

Může se také objevit ještě nějaká jiná nová technologie, která nakope ty jmenované

[Bystroushaak]

D naopak získává čím dál větší „trakci“. Já nechci vypadat že to nějak tlačím, protože jsem na to asi 4 roky nesáhl a prostě vůbec nemám potřebu to nějak shillovat, jen co vidím v /r/programming, tak není týden, aby o tom nebyl článek / zprávička. Vůbec se to nedá srovnávat s tou situací před pár lety, kdy to byl zapadlý projekt s komunitou o velikosti pár set lidí.

Osobně mám momentálně snahu o přesný opak, než o systémové jazyky. Tak nějak čím víc o tom vím, tím míň s tím chci mít společného. Přijde mi žádoucí vypadnout z vertikálního pekla^[1] prehistorických hoven postavených na hovnech do nějakého pokročilého VM a dál fungovat jen z něj, včetně rozšiřování zevnitř, nikoliv z venku. Ale je to dlouhodobý cíl s nejistým výsledkem a možná jsem jen naivní.

[tukan]

D naopak získává čím dál větší „trakci“. Já nechci vypadat že to nějak tlačím, protože jsem na to asi 4 roky nesáhl a prostě vůbec nemám potřebu to nějak shillovat, jen co vidím v /r/programming, tak není týden, aby o tom nebyl článek / zprávička. Vůbec se to nedá srovnávat s tou situací před pár lety, kdy to byl zapadlý projekt s komunitou o velikosti pár set lidí.

Osobně mám momentálně snahu o přesný opak, než o systémové jazyky. Tak nějak čím víc o tom vím, tím míň s tím chci mít společného. Přijde mi žádoucí vypadnout z vertikálního pekla^[1] prehistorických hoven postavených na hovnech do nějakého pokročilého VM a dál fungovat jen z něj, včetně rozšiřování zevnitř, nikoliv z venku. Ale je to dlouhodobý cíl s nejistým výsledkem a možná jsem jen naivní.

Dost brutální kniha, jako výběr .). Každopádně mám to podobně, proto jsem si vybral Ruby a nakonec skončil u Smalltalku (který jsem úplně zapomněl a znova ho oprašuji.) "nějakého pokročilého VM" No a tady je to právě ten kámen úrazu. Třeba že Smalltalk měl spousty a spousty času nejpokročilejší VM tam určitě není. Dnešní počítače mají vlastně brutální výkon (naprosto dostačující pro většinu věcí co člověk programuje), ale člověk ho vlastně nemůže využít.

[Bystroushaak]

Tím pokročilým VM jsem nemyslel nutně vlastnosti (jestli to běží o 20% pomaleji, jestli to neumí nativní thready a tak podobně), které jsou mi docela ukradené, ale spíš to IDE, styl vývoje a tak nějak obecně uživatelská stránka. Uznávám, že jsem to blbě napsal, chtěl jsem spíš napsat „pokročilou image“ běžící nad VM.

Výkonu mám tolik, že i kdybych 9/10 nějak zrušil, tak je to pořád víc, než jsem 99% času schopný využít.

[tukan]

Aha tak tomu jsme si nerozumněli. Na jednodušší věci výkonu je opravdu dost, ale při déle běžících věcech nebo neuronových síťích je výkon zapotřebí.

Zajímalo by mě co byste zlepšil na současném IDE např. StX nebo Pharo? (Sám mám nějaký názor, ale tím Vás nechci ovlivňovat.)

[Bystroushaak]

Zajímalo by mě co byste zlepšil na současném IDE např. StX nebo Pharo? (Sám mám nějaký názor, ale tím Vás nechci ovlivňovat.)

Tak já jsem v tomhle prakticky taky začátečník, navíc jsem na to teď půl roku zase nesáhl (měl jsem zakázku která mi žrala volný čas a teď vstřebávám Self). Určitě bych chtěl lepší podporu pro git, ale jak už padlo v diskuzi na tom už se pracuje. Jinak se mi v tom dělá docela dobře.

[Pavel Křivánek]

S brzkou podporou nativních vláken se alespoň v brzké době nepočítá. Pharo spíše zbaběle půjde cestou více spolupracujících samostatných procesů se specializovanými image a komunikací mezi nimi.

Na vylepšení podpory Gitu teď pracuje jeden full-time vývojář, tak by se to mělo pohnout kupředu.

[tukan]

S brzkou podporou nativních vláken se alespoň v brzké době nepočítá. Pharo spíše zbaběle půjde cestou více spolupracujících samostatných procesů se specializovanými image a komunikací mezi nimi.

To je opravdu velká škoda. Hlavně vzhledem k tomu jaký měl Smalltalk náskok například před například Java(ou). Chápu, že tvorba VM není jednoduchá práce a je plná kompromisů, ale holt rýpnout se do toho bude muset, pokud Smalltalk chce nějakým způsobem přežít a dostat se na výsluní.

Jaký se počítá že bude stát (výkonu) ta komunikace mezi těmi image? (zhruba samozřejmě)

Na vylepšení podpory Gitu teď pracuje jeden full-time vývojář, tak by se to mělo pohnout kupředu.

Perfektní to rád slyším.

[Pavel Křivánek]

Vícevláknová VM je jen část problému a možná dokonce ta menší. Vyžadovalo by to ještě masivní úpravy na straně image.

Mělo by se jednat o víc obrazů sdílejících jednu vícevláknovou VM a pak by dokonce mohlo být možné přímo sdílet některé objekty. Obávám se ale, že alespoň pro začátek se bude hodně zapojovat pomalá serializace a proxy objekty, viz např. Seamless [1].

[1] http://smalltalkhub.com/#!/~Pharo/Seamless

[tukan]

Vícevláknová VM je jen část problému a možná dokonce ta menší. Vyžadovalo by to ještě masivní úpravy na straně image.

Otázkou je pak jestli je image opravdu v současné době tak zapotřebí, aby brzdila vývoj (IMHO, pro vývoj ve více lidech asi zapotřebí tolik nebude) VM. Nápady od boku: Podle mě by pak bylo možno image uložit pouze v nějakém stavu (buď, že není spuštěna aplikace či thready doběhly a jsou v klidu.) nebo místo image použít verzovací systém a vždy podle potřeby překompilovat celý systém jak to jde u StX (Honza Vraný to má udělané moc pěkně kontinuálně se mu kompiluje StX a změny má hned začleněné pokud potřebuje.)

Mělo by se jednat o víc obrazů sdílejících jednu vícevláknovou VM a pak by dokonce mohlo být možné přímo sdílet některé objekty. Obávám se ale, že alespoň pro začátek se bude hodně zapojovat pomalá serializace a proxy objekty, viz např. Seamless [1].

[1] http://smalltalkhub.com/#!/~Pharo/Seamless

Hmm to je zajímavý nápad, i když mám trochu obavy pokud bude ten program mít těch vláken hodně, že to bude trochu problém uřídit a ty nároky té jedné vícevláknové VM budou drasticky narůstat.

[Jan Vrany]

Otázkou je pak jestli je image opravdu v současné době tak zapotřebí, aby brzdila vývoj (IMHO, pro vývoj ve více lidech asi zapotřebí tolik nebude) VM.

On to Pavel myslel jinak - tim "image" myslel smalltalkovy kod. To je skutecne mnohem vetsi problem. Staci se podivat na mnozstvi blockInterrupts / unblocInterrupts t typicke smalltaove knihovne. Nebo projit mailing listy aby kolikrat se nekdo pta jestli muze dojit ke context-switch mezi

a := value1. b := value2.

Obvykle je odpoved ze ne. Tenhle kod se rozpadne jako domecek z karet. Pokud chces multithreadovou VM, musis mit multithreadovou knihovnu a to zadny soucasny smalltalk nema. Je potreba ji napsat.

[tukan]

On to Pavel myslel jinak - tim "image" myslel smalltalkovy kod. To je skutecne mnohem vetsi problem. Staci se podivat na mnozstvi blockInterrupts / unblocInterrupts t typicke smalltaove knihovne. Nebo projit mailing listy aby kolikrat se nekdo pta jestli muze dojit ke context-switch mezi

a := value1. b := value2.

Obvykle je odpoved ze ne. Tenhle kod se rozpadne jako domecek z karet. Pokud chces multithreadovou VM, musis mit multithreadovou knihovnu a to zadny soucasny smalltalk nema. Je potreba ji napsat.

Aha, tak to je průšvih. To bude/by bylo na dlouho.

[Pavel Křivánek]

Nápady od boku: Podle mě by pak bylo možno image uložit pouze v nějakém stavu (buď, že není spuštěna aplikace či thready doběhly a jsou v klidu.) nebo místo image použít verzovací systém a vždy podle potřeby překompilovat celý systém jak to jde u StX (Honza Vraný to má udělané moc pěkně kontinuálně se mu kompiluje StX a změny má hned začleněné pokud potřebuje.)

V příští verzi Phara už prakticky jistě bude fungovat bootstrap, tzn. že se image bude generovat nová ze zdrojových kódů z verzovacího systému, což mimo jiné výrazně usnadní případné výrazné změny v systému. Možnost ukládání image samozřejmě stále zůstane. Také se citelně zlepší modularita.

[tukan]

Nápady od boku: Podle mě by pak bylo možno image uložit pouze v nějakém stavu (buď, že není spuštěna aplikace či thready doběhly a jsou v klidu.) nebo místo image použít verzovací systém a vždy podle potřeby překompilovat celý systém jak to jde u StX (Honza Vraný to má udělané moc pěkně kontinuálně se mu kompiluje StX a změny má hned začleněné pokud potřebuje.)

V příští verzi Phara už prakticky jistě bude fungovat bootstrap, tzn. že se image bude generovat nová ze zdrojových kódů z verzovacího systému, což mimo jiné výrazně usnadní případné výrazné změny v systému. Možnost ukládání image samozřejmě stále zůstane. Také se citelně zlepší modularita.

Konečně! To rád slyším i jsem si všimnul, že Pharo 5.0 doplňuje kód, což také oceňuji. Je paráda, že někdo ze Smalltalkové komunity má rozum a začleňují se věci které dnešní vývojář má za standard.

[Bystroushaak]

i jsem si všimnul, že Pharo 5.0 doplňuje kód, což také oceňuji

To už afaik dělalo i Pharo 4.

[tukan]

To máte pravdu, to jsem zapomněl.

[deda.jabko]

Proc zbabele?

Smalltalk sice neni uplne muj salek caje, ale neni zakladem objektoveho paradigmatu zasilani zprav? A co by mohlo byt vic OOP nez jednotlive procesy komunikujici pomoci zasilani zprav?

[Pavel Křivánek]

Protože opravdu odvážné řešení by bylo mít kompletní promisní zasílání zpráv se samostatným procesem pro každou z nich

[deda.jabko]

To jo. A ma to nekde nekdo?

[Pavel Křivánek]

V praxi samozřejmě nikdo, protože režie takového systému by byla nepřijatelně velká. To ale na druhou stranu neznamená, že by se nedalo předstírat, že tomu tak skutečně je a chovat se podle toho. Přístup, kdy se k problému přistupuje opravdu nekompromisně obecně a pak se hledají cesty, jak to v praxi realizovat efektivně, se z dlouhodobého hlediska vyplatí.

V jazycích, které se snaží o paralelismus v OO, se častěji uplatňují paralelní kontejnery objektů. A právě takovým přirozeným kontejnerem je právě image. To je cesta, kterou Pharo směřuje.

[kralyk z abclinuxu]

Přístup, kdy se k problému přistupuje opravdu nekompromisně obecně a pak se hledají cesty, jak to v praxi realizovat efektivně, se z dlouhodobého hlediska vyplatí.

Ještě jsem neviděl případ, kdyby se to skutečně vyplatilo.

Reálně použitelné jazyky / platformy budou vždy z ideologického hlediska špatné.

[tukan]

Jestli se nepletu tak tohle je myšlenka založena na původní myšlence Alana Kay(e), že Smalltalk měl imitovat chování buněk v organismu a tam také dochází k masivně paralelní komunikaci.

Zajímavé ale na tom je přeci to, že spousty komunikace je implicitní, t.j. řídící jednotka (mozek) o tom vůbec neví ale i tak k ní dochází a je to jen z důvodu nastaveného systému a jeho chování.