Portál AbcLinuxu, 2. května 2025 08:31
Diskuse byla administrátory uzamčena.
Dík za blog post. Kdysi jsem zkoušel smalltalk ale bylo to na mě moc alien, to samé je i se selfem. Myslím že self a smalltalk potkalo to samé co lisp. Byli moc dobrý a moc jiný.Bude i kapitola „Self z hlediska historického“, kde je přesně popsáno co se zvrhlo a proč Self umřel.
Třeba si nedovedu představit řešení merge konfliktů v té transportní notaci. Jak se to řešilo? Serializací do čitelného kódu a nebo něčím specifickým pro self?Nijak, ten transporter vznikl dávno před plošným rozšířením distribuovaných VCS. Ale ono to není zas tak hrozné, prostě si oba dva objekty můžeš importovat do běžícího Selfu a porovnat je tam. Ty commity v githubu taky nejsou zas tak moc nepřehledné.
Da se nejak rozumne udelat diff dvou image?To by afaik mělo jít, ale nezkoušel jsem.
Dá sa so selfom ovládať USB alebo sériový port na bežnom počítači? Je k tomu nejaký hotový objekt (knižnica objektov) na ovládanie USb alebo serioveho portu ? Programujem embedded (C, C++, Qt, TI RTOS), potrebujem ovladať skutočný hardvér (cez USB alebo seriovu linku).Umí to bindingy na C knihovny a samotné je to psané v C++, takže porty by neměly být problém.
Myslíte si že by mal Self pre mna zmysel ?Myslím si že ne.
Díky za tenhle článek. Je to úplně jiný svět, než ve kterém se většina programátorů pohybuje a je dobré si takhle rozšiřovat obzory. Asi pro tenhle přístup nemám praktické využití, ale zajímavé to je. Zde je pár mých komentářů, některé trochu rýpavé, ale není to myšleno ve zlém:
Zvěst o grafickém prostředí nabízejícím možnosti jako žádné jiné, leč skoro nikdo ho nepoužívá.
Pominu ten příšerný vzhled… Nicméně, jak fungují třeba okna, na která natahám pár GUI prvků? Bude se při změně velikosti okna měnit i velikost prvků uvnitř nebo zůstanou na fixních pozicích s fixní velikostí? Půjde tam naklikat, který prvek se má roztahovat společně s oknem a který má zůstat fixní? Tohle je třeba věc, která šla v Netbeans naklikat před víc jak deseti lety a už tehdy to bylo krásně intuitivní a prostě to fungovalo.
Obraz paměti v sobě obsahuje celé vývojové prostředí a vlastní grafické rozhraní s bindingy na Xlib. Také jsou v něm kompilátory pro programovací jazyk, celá standardní knihovna a tak podobně. … Transporter je Selfový způsob, jak z objektů v paměti udělat zpět zdrojový kód, který se dá poté třeba verzovat v klasických VCS, jako je Git. … Vyexportovaný kód je poněkud nečitelný … Nutno ovšem dodat, že se jedná o serializaci, kde není zamýšlena editace programátorem, účelem je primárně distribuce a verzování. Editace by správně měla probíhat vždy uvnitř prostředí samotného Selfu přímou manipulací objektů.
S tímhle mám trochu (dost) problém. Program by podle mého měl být pár řádků kódu, které si můžu přečíst, posoudit, zda to dělá, co má, případně upravit… a to „pár“ by mělo odpovídat komplexitě řešené úlohy. A ne, že to bude nějaký blob, ve kterém bude všechno dohromady a nebude tam jasná hranice mezi tím, co je program a co standardní knihovna a co volitelné nástroje atd. A nejde jen o nějakou auditovatelnost z pohledu „paranoika“, ale třeba i o možnost aktualizovat knihovnu, aniž bych měnil program. V případě zdrojáků a knihoven s jasně definovaným API to možné je, ale v případě obrazů paměti mi to přijde komplikovanější (nutnost část objektů vyjmout a nějak tam naroubovat jiné…).
Jako jazyk je Self velmi jednoduchý na naučení.
To už mi přijde srozumitelnější Lisp/Scheme, než tohle. Osobně mi nijak nevadí syntaxe vycházející z C a klidně bych se jí držel. Chápu, že tohle je dost o zvyku a do jisté míry subjektivní, ale nevidím céčkovskou syntaxi (obohacenou o nějaké funkcionální prvky) jako překážku efektivní práce. Klidně na ní může být postavený můj ideální/dokonalý jazyk.
Autoři se poměrně úspěšně snažili nabídnout uživatelům možnost vytvářet poměrně jednoduchým způsobem vlastní grafická rozhraní, což je jinak věc, která je pro běžné lidi nad rámec Powerpointu prakticky nemožná.
GUI si naklikáš (i jako uživatel) třeba v LibreOffice Base (Formuláře, Sestavy). Na jednoduché GUI průvodce ti stačí Bash + Zenity. To taky zvládne uživatel. Pak tu jsou Netbeans, QtCreator, Glade… kde si GUI taky naklikáš i jako uživatel (nicméně, abys to GUI oživil a něco dělalo, tak už musíš umět trochu programovat).
Takže tohle mi nepřijde jako nějaká exkluzivní vlastnost Selfu.
Pěkný příklad je pokud si zobrazíte outliner pro nil. V ukázce jde pěkně vidět, jak dva sloty ukazují na jeden konkrétní objekt. Outliner pro konkrétní objekt by neměl být na obrazovce víc jak jednou.
Zajímavé je dívat se na prázdnou hodnotu taky jako na objekt. A jak to funguje třeba pro čísla? Když budu mít někde pět rohlíků a jinde pět let staré auto, bude to oboje ukazovat na tu samou pětku? Ukazuje to na neměnnou „pětku“ a při změně hodnoty to začne ukazovat jinam, nebo se změní obsah té „pětky“ na něco jiného? (tzn. ukazatel/reference vs. hodnota)
Na první pohled podivný zaměřovač s šedým boxem umožňuje provádět reflexi celého morphic interface zobrazením z čeho se skládá prostě tím, že ho myší přesunete nad konkrétní prvek který si přejete prozkoumat
Pro Qt existuje GammaRay. Chápu, že postavit takový nástroj nad Qt nebo třeba Javou nedá tak dokonalý výsledek, jako když je to přímo součást jazyka, ale otázka je, zda je ten rozdíl z pohledu praktické použitelnosti relevantní. Ve vedlejší diskusi píšeš, že jsi pragmatik. A tohle mi zase přijde jako striktně idealistický přístup a honba za jakousi dokonalostí – místo toho, abys použil nedokonalé, ale reálně dostupné řešení. V zásadě to není problém, člověk může být v něčem pragmatik a v něčem idealista a je to subjektivní. Já bych se třeba rozhodoval jinak, např. bych nepoužíval proprietární službu/software, ale klidně použiji „nedokonalý“ jazyk s nedokonalou reflexí nebo (dle někoho) „zmrveným“ OOP.
Pominu ten příšerný vzhled… Nicméně, jak fungují třeba okna, na která natahám pár GUI prvků? Bude se při změně velikosti okna měnit i velikost prvků uvnitř nebo zůstanou na fixních pozicích s fixní velikostí? Půjde tam naklikat, který prvek se má roztahovat společně s oknem a který má zůstat fixní? Tohle je třeba věc, která šla v Netbeans naklikat před víc jak deseti lety a už tehdy to bylo krásně intuitivní a prostě to fungovalo.
Dá se to naklikat tak i tak. By default se afaik prvky roztahují společně s oknem.
S tímhle mám trochu (dost) problém. Program by podle mého měl být pár řádků kódu, které si můžu přečíst, posoudit, zda to dělá, co má, případně upravit… a to „pár“ by mělo odpovídat komplexitě řešené úlohy. A ne, že to bude nějaký blob, ve kterém bude všechno dohromady a nebude tam jasná hranice mezi tím, co je program a co standardní knihovna a co volitelné nástroje atd. A nejde jen o nějakou auditovatelnost z pohledu „paranoika“, ale třeba i o možnost aktualizovat knihovnu, aniž bych měnil program. V případě zdrojáků a knihoven s jasně definovaným API to možné je, ale v případě obrazů paměti mi to přijde komplikovanější (nutnost část objektů vyjmout a nějak tam naroubovat jiné…).
S tím do jisté míry souhlasím a například chci mít transporter, který extrahuje lidsky čitelnou reprezentaci tak, jako kdyby to byl čistý Self kód. Vskutku nevím, proč to tak David Ungar nenaprogramoval a doufám, že v tom není nějaký chyták.
Transporter je z tvého pohledu v podstatě package manager (který teda v Selfu v celé komplexnosti chybí).
Přemýšlel jsem nad tím jak tohle řešit a mám pár nápadů, tak se uvidí.
To už mi přijde srozumitelnější Lisp/Scheme, než tohle. Osobně mi nijak nevadí syntaxe vycházející z C a klidně bych se jí držel. Chápu, že tohle je dost o zvyku a do jisté míry subjektivní, ale nevidím céčkovskou syntaxi (obohacenou o nějaké funkcionální prvky) jako překážku efektivní práce. Klidně na ní může být postavený můj ideální/dokonalý jazyk.
¯\_(ツ)_/¯
V příštím díle budou další ukázky. Ta syntaxe je v podstatě Smalltalk s literály pro objekty, podobně jako má třeba smalltalk literály pro bloky.
GUI si naklikáš (i jako uživatel) třeba v LibreOffice Base (Formuláře, Sestavy). Na jednoduché GUI průvodce ti stačí Bash + Zenity. To taky zvládne uživatel. Pak tu jsou Netbeans, QtCreator, Glade… kde si GUI taky naklikáš i jako uživatel (nicméně, abys to GUI oživil a něco dělalo, tak už musíš umět trochu programovat).
Takže tohle mi nepřijde jako nějaká exkluzivní vlastnost Selfu.
To jsem nikdy neviděl použité. Maximum co jsem kdy viděl bylo použití dialogu z shell scriptu a to už se jednalo o vcelku pokročilé uživatele na pomezí programátorů.
Zajímavé je dívat se na prázdnou hodnotu taky jako na objekt. A jak to funguje třeba pro čísla? Když budu mít někde pět rohlíků a jinde pět let staré auto, bude to oboje ukazovat na tu samou pětku? Ukazuje to na neměnnou „pětku“ a při změně hodnoty to začne ukazovat jinam, nebo se změní obsah té „pětky“ na něco jiného? (tzn. ukazatel/reference vs. hodnota)
Prázdná hodnota je objekt nil. Čísla jsou afaik neměnná, ale ten objekt co je obaluje bude měnitelný. Nevím přesně jak je to implementované v Selfu, ale imho to bude podobně jako třeba v pythonu.
Pro Qt existuje GammaRay. Chápu, že postavit takový nástroj nad Qt nebo třeba Javou nedá tak dokonalý výsledek, jako když je to přímo součást jazyka, ale otázka je, zda je ten rozdíl z pohledu praktické použitelnosti relevantní.
On je hlavní problém v tom, že jak Qt, tak Java nejsou na prototypech založené jazyky. Takže cokoliv co s tím uděláš je dál nepoužitelné. V Selfu ty prototypy, které jsi sestavil třeba z kusů jiné aplikace dál používat a pokud to vhodně rekurzivně oanotuješ, tak třeba i distribuovat a serializovat zpět do zdrojáků.
Ve vedlejší diskusi píšeš, že jsi pragmatik. A tohle mi zase přijde jako striktně idealistický přístup a honba za jakousi dokonalostí – místo toho, abys použil nedokonalé, ale reálně dostupné řešení. V zásadě to není problém, člověk může být v něčem pragmatik a v něčem idealista a je to subjektivní. Já bych se třeba rozhodoval jinak, např. bych nepoužíval proprietární službu/software, ale klidně použiji „nedokonalý“ jazyk s nedokonalou reflexí nebo (dle někoho) „zmrveným“ OOP.
Je dobré rozlišovat kontext. Tenhle seriál jsem začal psát, abych vysvětlil Self jako takový. O něm toho v ČR a obecně ve světě nebylo moc napsáno, proto mi to přišlo smysluplné. Prakticky nikdo to navíc nevysvětluje prakticky, tedy s ukázkami jak v tom fakt dělat.
Co se týče mně, tak si nejsem úplně jistý, jestli pro svůj jazyk budu chtít morphic a na morphicu založený interface, spíš použiju něco s omezenou reflexí.
S tímhle mám trochu (dost) problém. Program by podle mého měl být pár řádků kódu, které si můžu přečíst, posoudit, zda to dělá, co má, případně upravit… a to „pár“ by mělo odpovídat komplexitě řešené úlohy. A ne, že to bude nějaký blob, ve kterém bude všechno dohromady a nebude tam jasná hranice mezi tím, co je program a co standardní knihovna a co volitelné nástroje atd. A nejde jen o nějakou auditovatelnost z pohledu „paranoika“, ale třeba i o možnost aktualizovat knihovnu, aniž bych měnil program. V případě zdrojáků a knihoven s jasně definovaným API to možné je, ale v případě obrazů paměti mi to přijde komplikovanější (nutnost část objektů vyjmout a nějak tam naroubovat jiné…).Takto pojate objektove orientovane programovani je z principu tezce antimodularni. Ostatni OOP jazyky maji s antimodularitou taky problem, ale snazi se to aspon nejak resit, ale nemyslim, ze by to lidi kolem Smalltalku/Selfu nejak trapilo. Mimochodem, i ty siroke moznosti reflexe, o kterych bystroushak psal, jsou v principu proti dobrym zasadam objektoveho programovani.
Takto pojate objektove orientovane programovani je z principu tezce antimodularni.
Ten můj komentář nebyl cílený na OOP, ale obecně na programování. Je celkem jedno, jestli to jsou objekty, funkce, procedury… Vždycky je důležité mít dobře definovaná rozhraní, a pak lze z menších částí skládat větší celky. Bez těch rozhraní to sice můžeš začlenit, ale už si neupgraduješ knihovnu nebo nevyměníš jednu implementaci za jinou.
U OOP jsou někdy problémy se znovupoužitelností kvůli tomu, že každá knihovna používá jiné typy – pak to na sebe nepasuje a je potřeba vytvářet nějaké překladové vrstvy. U funkcionálního přístupu se to na první pohled neděje – ale to je spíš dané menší granularitou a tím, že hodně těch funkcí pracuje jen s primitivními datovými typy, takže na sebe napojit jdou. Pokud tam ale začneš používat vlastní typy, tak máš stejný problém jako u toho OOP a je nutné data nějak překládat (ve chvíli kdy proudí z funkcí jedné knihovny do funkcí jiné).
Ten můj komentář nebyl cílený na OOPA ten muj komentar byl mireny na jazyky typu Smalltalk/Self, kdy pristup k tvorbe programu (rj. chuchvalci provazanych objektu) prilis nepodporuje tvorbu jasne definovanych rozhrani.
problém z toho děláš bez ohledu že bys udělal třeba nějakou studii. Tím netvrdím opak, tedy že to k tomu nikdy nevede, pouze že sám jsem to nepozoroval a asi by bylo dobré se opřít o tvrdá data, než odsoudím celé paradigma.Oblibena argumentacni figura, ale budiz. V PL vyzkumu je obecne (a z principu) problem se studiemi tohoto typu (k tomu uz jsem par studii videl), takze nepredpokladam, ze by existovala konkretni studie ke Smalltalku nebo Selfu, ktera by se tu dala pouzit.
sám jsem to nepozoroval a asi by bylo dobré se opřít o tvrdá dataU dostatecne dlouho vyvijenych projektu vidam casto scenar, ze se na zacatku nacrtnou moduly, jejich zodpovednosti a rozhrani, chvilku se to drzi, ale po case pres ta rozhrani zacnou jednotlive objekty plynout, sdilet se, propletat se, a de facto zacnou fungovat jako dalsi rozhrani s hodne fraktalnimi vlastnostmi. Vzdycky jsme mel pocit, ze Smalltalk k necemu takovemu vylozene inspiruje.
Jinak třeba Python má reflexi asi na stejné úrovni, jako Smalltalk a jen o trochu nižší, než Self a k tebou popisovanému hovnokódu to nevede. Čím to bude?Uklidnime se. Ta poznamka k te reflexi nebyla ani tak ke kvalite kodu, ale k objektovosti tech programovacich jazyku, protoze je to takove docela pokrytecke. Na jednu stranu se tvarime, jak je objektove programovani hlavne o zapouzdreni a posilani zprav a jak jsou objekty cerne skrinky. A pak to reflexe cele postavi na hlavu.
Oblibena argumentacni figura, ale budiz. V PL vyzkumu je obecne (a z principu) problem se studiemi tohoto typu (k tomu uz jsem par studii videl), takze nepredpokladam, ze by existovala konkretni studie ke Smalltalku nebo Selfu, ktera by se tu dala pouzit.Nerozporuji že by k tomu mohlo dojít, ale že k tomu běžně dochází v těch jazycích jen protože to umožňují. Ostatně to je tak neoptimální a opruzné, že by takové jazyky prostě nikdo nepoužíval.
U dostatecne dlouho vyvijenych projektu vidam casto scenar, ze se na zacatku nacrtnou moduly, jejich zodpovednosti a rozhrani, chvilku se to drzi, ale po case pres ta rozhrani zacnou jednotlive objekty plynout, sdilet se, propletat se, a de facto zacnou fungovat jako dalsi rozhrani s hodne fraktalnimi vlastnostmi. Vzdycky jsme mel pocit, ze Smalltalk k necemu takovemu vylozene inspiruje.Já ten pocit nemám, ale je fakt, že ve Smalltalku jsem dělal relativně málo. V Selfu si nějak netroufám tvrdit, momentálně je v takovém stavu, že cokoliv by bylo lepší než to nic co je tam teď..
Uklidnime se. Ta poznamka k te reflexi nebyla ani tak ke kvalite kodu, ale k objektovosti tech programovacich jazyku, protoze je to takove docela pokrytecke. Na jednu stranu se tvarime, jak je objektove programovani hlavne o zapouzdreni a posilani zprav a jak jsou objekty cerne skrinky. A pak to reflexe cele postavi na hlavu.Eh? Jsem úplně v klidu. To že je něco možné přece neznamená, že to hned všichni budou používat a zneužívat, speciálně když tím objektivně škodí sami sobě. Reflexe je například nedocenitelná při interaktivním programování. Smalltalk interaktivní programování podporuje a propaguje docela hodně, takže to má svoje výhody, kde ti to umožňuje koukat a lépe vidět co se skutečně děje. Sám často používám podobný styl vývoje, kde si v pythonu někam hodím pdb a prostě se koukám co se tam děje. Osobně jinak více/méně souhlasím, že až na některé okrajové případy, jako je třeba serializace, pak reflexe není úplně vhodná technika k používání v samotném programu. Ale to je přece docela podstatný rozdíl. Jinak mimochodem, v mém jazyce je dělaná přes mirrory a jde vypnout.
popořákdu má být samozrejme nepořádku
Na druhou stranu jsou ale problémy s distribucí změn mezi uživateliJak to? Vždyť z toho prostě uděláš balíček jako třeba v případě githubu a hodíš to na smalltalkhub a ostatním se to samo nabídne jako aktualizace ke stažení.
Trávit půl života v debugeru mi přijde jako noční můra a to nemluvím o tom, že mi v něm běží vlastně celý systém a já ho za běhu ještě k tomu modifikuju. Nevěřím tomu, že se tímhle způsobem dá vytvořit něco co robustně funguje, spíš je to takové nekonečné hackování, ale pokud je to cíl, tak proč ne.Tohle je hrozně vtipné v kontextu Smalltalku používaného velkými bankami, kde dřív byl Smalltalk považován za něco jako dneska Java, tedy univerzální business jazyk, ve kterém se píšou ty velké a spolehlivé systémy. A mimochodem to na tom dodneška běží, před pár lety mě lákali na pohovor i tady v Praze.
jako třeba v případě githubuOmg, chtěl jsem napsat jako třeba v případě pypi (pythonní package repository).
Prototypova dedicnost v JS mi nikdy k srdci neprirostla a v poslednich verzich jazyka se od ni vlastne upustilo. Dava to Selfu oproti Smalltalku neco navic?Prototypy v JS pokud vím nemají delegaci, protože přestože Self byl jedna z inspirací pro javascript, tak bohužel zrovna tohle bylo opomněno. Bez ní to moc nedává smysl. Prototypy jsou přímo použitelné k reprezentaci dokumentů, což je jeden z experimentů, který chci vyzkoušet. Class based jazyky to komplikují dualitou mezi instancí objektu a jeho třídou. Self je v tomhle "ideologicky čistější".
Smalltalk ma vetsi komunitu a Squeak/Pharo jsou v podstatne lepsim stavu. Takze proc Self?Protože se mi víc hodí. To zase není, jako že bych Smalltalk ignoroval, předtím jsem věnoval asi rok a něco, abych se naučil Pharo a pořád to trochu po očku sleduji. Self má svojí koncepcí blíž k lispu, ale to asi teď z hlavy nezvládnu líp vysvětlit.
Prototypy jsou přímo použitelné k reprezentaci dokumentů, což je jeden z experimentů, který chci vyzkoušet. Class based jazyky to komplikují dualitou mezi instancí objektu a jeho třídou. Self je v tomhle "ideologicky čistější".
Ve Smalltalku lze vytvořit objekt, který je svou vlastní třídou, takže ta dualita není absolutní. Jenže potom je člověk stejně omezen jen jedním "rodičovským slotem".
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.