OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Víte že můžete odebírat mé blogy pomocí RSS? (Co je to RSS?)
Od určité doby jsou všechny texty které zde publikuji verzované na Githubu.
Jestliže najdete chybu, nepište mi do diskuze a rovnou jí opravte. Github má online editor, není to skoro žádná práce a podstatně mi tím usnadníte život. Taky vás čeká věčná sláva v commit logu :)
2.2.2019 22:18
| Přečteno: 2513×
| Obecné IT
| 
| poslední úprava: 10.5.2019 17:34
Přináším vám zvěst o jazyku, který stál u zrodu mnoha dalších, leč skoro nikdo ho nezná. Zvěst o grafickém prostředí nabízejícím možnosti jako žádné jiné, leč skoro nikdo ho nepoužívá. Přináším také zvěst o virtuální mašině podporující reflexi téměř do nekonečna, a svého času dosahující v numerických výpočtech výkonu poloviny C, přesto dnes zapomenuté.
Dnes vám budu povídat o Selfu. Různí lidé řekli o Selfu různé věci:
Self je (jako) Smalltalk, jen víc.
Self je moře objektů, skrz které proudí záblesky zpráv.
Self je natolik pokročilá představa budoucnosti z pětadvacet let staré minulosti, že je stále pořád víc, než jen inspirativní. Vizionářská je to správné slovo.
I liked Self. “Good OOP” is still waiting for a much better notion to replace the idea of a “Class”
— Alan Kay, https://news.ycombinator.com/item?id=11939851#11941380
The only other language of promise is Self, and that is unfunded and locked in non-development though so incredibly influential.
— http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=4
Softwarová archeologie v praxi. Bohatý poklad, o kterém nikdo neví a který nikdo nepoužívá. Stovky tisíc řádků zapomenutého kódu, myšlenek, nápadů.
Self je mnoho věcí, podíváme se na něj tedy z mnoha různých hledisek.
Self je programovací jazyk, interpret bytecode a systém „obrazů“ paměti (dále jen image), které jsou tímto interpretrem vykonávány.
Prakticky je to binárka s virtuálním strojem a k tomu separátně soubor image paměti, ve které jsou uloženy objekty tvořící prostředí. Situace se trochu podobá běžným scriptovacím jazykům, akorát místo scriptu spouštíte obraz paměti ve stavu, v němž script minule skončil.
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ě.
Programovací jazyk Self je na prototypech založený, objektově orientovaný jazyk Smalltalkovského typu.
Na prototypech založený znamená, že nepoužívá třídy k tvorbě objektů. Nové objekty vznikají buďto kopírováním, nebo na syntaktické úrovni vytvořením nového objektu ze zdrojového kódu.
Smalltalkovského typu znamená, že vše se točí kolem posílání zpráv objektům. Kromě pár základních syntaktických cukrátek zde nenajdete nic jiného, než posílání zpráv sem a tam.
Jako jazyk je Self velmi jednoduchý na naučení. Prakticky všechny vlastnosti programovacího jazyka se vejdou na jednu stránku o velikosti A4 i s popisky a vysvětlivkami.
Tolik tedy ke krátkému přehledu. Podrobnostem se budu dále věnovat v následujících kapitolách.
Interpret a základní obraz si můžete stáhnout z oficiálních stránek http://www.selflanguage.org/. K dispozici jsou binární distribuce pro GNU/Linux a Mac OS X. Dostupné jsou také zdrojové kódy pod OpenSource licencí, které si teoreticky můžete zkompilovat všude možně.
Prakticky to ale zas tak jednoduché nejspíš nebude, kvůli bindingům na grafický server a kvůli JIT kompilátorům, které je nutné odladit přímo na konkrétní rodinu procesoru.
Po stažení a rozbalení archivu na vás čekají hlavní soubory a několik vedlejších. Ty hlavní jsou:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czSelf
morphic.snap
První soubor je spustitelná binárka interpretru, druhý soubor je obraz paměti, do kterého bylo uloženo před-připravené prostředí s grafickým rozhraním.
Po spuštění je možné nechat si vypsat nápovědu:
$ ./Self -h
./Self: usage: ./Self [-f filename] [-h] [-s snapshot] ...
Options:
-f filenameReads filename (Self source) immediately after startup
-hPrints this message
-pDon't do `snapshotAction postRead' after reading snapshot
-s snapshotReads initial world from snapshot
-wSuppress warnings about optimized code being discarded
For debugging use only:
-FDiscards saved code from snapshot
-l logfilewrite spy log to logfile
-rDisable real timer
-tDisable all timers
-cUse real timer instead of CPU timer (for OS X)
-oOversample the timers (Run them 10x faster to flush out bugs)
-aTest the Assembler (added for Intel)
Other command line switches may be interpreted by the Self world
Pokud místo nápovědy uvidíte cosi jako
./Self: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
pak používáte 64 bitový systém, který nemá nainstalovanou podporu 32 bitových programů. Na debianu je možné nainstalovat potřebnou podporu následujícím způsobem:
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libx11-6:i386 libxext6:i386 libtinfo5:i386
Zajímavé jsou v podstatě jen dva switche; -f, pro načtení .self souboru (což pravděpodobně jen tak nepoužijete) a -s, který načítá uložený obraz paměti. Zbytek jsou vesměs technické detaily vhodné pouze pro velmi pokročilé uživatele.
Pokud spustíte Self samotný, objeví se před vámi REPL (interaktivní režim), do kterého můžete psát příkazy:
$ ./Self
Self Virtual Machine Version 2017.1/13, Tue 16 May 17 00:45:42 Linux i386 (4.5.0-205-gd942ba2-dirty)
Copyright 1989-2016 AUTHORS (type _Credits for credits)
for I386: LogVMMessages = true
for I386: PrintScriptName = true
for I386: Inline = true
for I386: SICDeferUncommonBranches = false (not implemented)
for I386: SICReplaceOnStack = false (not implemented)
for I386: SaveOutgoingArgumentsOfPatchedFrames = true
VM#
Vzhledem k tomu, že Self jako interpret běžně operuje na úrovni image, a já žádnou nenačetl, jsem nyní v interpretru, kde kromě několika zabudovaných primitiv není v podstatě nic. Žádná standardní knihovna, skoro žádné objekty, kterým by se daly posílat zprávy. Self v tomhle stavu ani neumí sečíst dvě čísla, protože pořádně ani neví, co čísla znamenají.
Nápovědu je možné vypsat posláním zprávy (podrobnosti dále) help:
VM# help
'
To begin using Self, you must read in the world of Self objects.
To read in the world, type:
'worldBuilder.self' _RunScript
When this process is complete, you will be at the Self prompt.
At the Self prompt, you can start the user interface by typing:
desktop open
' <0>: ( | parent* = <1>. | byte array: {10, 9, 84, 111, 32, 98, 101, 103, 105, 110, 32, 117, 115, 105, 110, 103, 32, 83, 101, 108, ... (258 more elements) } )
VM#
Nápověda (v podobě vráceného stringu) však moc užitečná není, jediné co nám ukáže je jak načíst svět z .self scriptů posláním zprávy _RunScript stringu s cestou ke scriptu.
Toto se hodí, když chceme vyrobit nový, „čistý“ image ze serializovaných zdrojových kódů. Toho je docíleno postupným vytvořením tisíců objektů tvořících standardní knihovnu na základě používání několika zabudovaných primitiv. Také je na to možné nahlížet jako na vybudování systému pomocí několika axiomů.
Přiložený subor morphic.snap obsahuje takto sestavený svět propojených objektů, tvořící standardní knihovnu a několik užitečných aplikací. Také obsahuje vlastní uživatelské rozhraní, které je implementováno kompletně v Selfu, s několika backendy na grafický server (Xlib v případě Unixu/Linuxu, Quartz v případě OS X).
Self vás však nenutí používat tuto image. Můžete mít image, kde vůbec není grafické rozhraní, kde nejsou nahraná čísla, nebo kde je třeba jen webserver. Ačkoliv je v jedné image možné provozovat velké množství aplikací naráz, z praktických důvodů sám provozuji několik oddělených image.
Předtím, než se pustím do popisu jazyka bych rád prvně vysvětlil základy uživatelského rozhraní a vývojového prostředí Selfu.
Když Self poprvé spustíte, zobrazí se vám bílá obrazovka, jakási plocha. Umím si představit, že pro mnohé to může být šok. Když jsem sel poprvé pustil já, tak jsem ho po asi třiceti vteřinách zmateného koukání a klikání myší zase zavřel a smazal.
Strohá prázdná bílá plocha zrovna nepovzbuzuje k prozkoumávání toho na co jste narazili.
Věc, kterou je z dnešního uhlu pohledu poměrně těžké překousnout je, že stejně jako grafické rozhraní operačního systému Plan9, tak i Self vznikl v době velkého nadšení z tehdy nové periferie: myši. Tvůrci si od ní slibovali velkou intuitivnost ovládání, proto se rozhodli udělat celé prostředí ovladatelné primárně z myši.
Věřte mi, že pokud si myslíte, že víte co očekávat z klasických grafických klikacích aplikací, tak nemáte tušení. V Selfu je myš nejenom primárním ovládacím prvkem, doslova kromě psaní kódu metod nemusíte na klávesnici ani sáhnout. I programovat se dá do jisté míry jen myší.
Pokud kliknete na plochu, tak levé i pravé tlačítko nedělají nic a prostřední vyvolá menu.
Z tohoto menu se dají (myší samozřejmě) vybrat základní nástroje a také je možné uložit obraz paměti, či vše ukončit.
Poměrně dlouho jsem si lámal hlavu jak tohle vlastně vysvětlit. Celé grafické rozhraní je programovací jazyk. Programovací jazyk je ovladatelný z grafického rozhraní, a věci, které se v něm dějí, se často zobrazují graficky.
Ten obdélník s nápisem shell vpravo nahoře představuje cosi jako konzoli, do které je možné psát příkazy. Zároveň se však také jedná o grafickou reprezentaci objektu programovacího jazyka, takzvaný outliner.
Šipka vlevo v roku umožňuje zobrazit jednotlivé sloty - prvky v objektu.
Jak je možné vidět, v tomto objektu jsou sloty db*, shortcuts* a help. První dva jsou takzvané parent sloty, tedy sloty odkazující se na objekty, do kterých je prováděna delegace nenalezených zpráv.
Tomuto objektu je možné poslat zprávu se jménem slotu a on vrátí její obsah. Zprávu je možné taky poslat graficky a on vrátí obsah graficky (bude ukázáno dále).
Tři tečky vedle názvu objektu umožňují zobrazit dokumentační komentář objektu.
Jedná se o docstring zadaný při vytvoření objektu.
Dále vidíme sérii tlačítek vpravo v rohu, které se zobrazují trochu divně, protože nemám nainstalované očekávané fonty. Tlačítko označené /\ zobrazuje parent sloty. Když na něj kliknu, ocitnou se mi na pozici kurzoru a já je dalším kliknutím můžu položit na plochu.
Že se jedná skutečně o parent sloty je možné zobrazit kliknutím na pravé boxíky na straně parent slotů:
Důležité tlačítko je E, které se zobrazuje u všech outlinerů. To vám zobrazí vstupní pole, kterým můžete objektu posílat zprávy.
Zde můžete vidět poslání zprávy help, kterou odešlu kliknutím dole na Get it, či stisknutím CTRL+enter. To shellu říká, aby mi vrátil outliner pro objekt stringu. Mohl bych také zmáčknout Do it, což by způsobilo provedení zprávy a zahození vrácené hodnoty.
Vrácený outliner je samozřejmě možné dále prozkoumávat:
Vrácenému objektu můžu posílat zprávy, referencovat ho z jiných objektů a tak podobně.
Za zmínku stojí, že celé prostředí se chová jako gigantická 2D plocha, po které je možné scrollovat a skákat pomocí WIN+šipka.
Uživatelské rozhraní se může zdát z dnešního pohledu ošklivé a divné. Je ovšem nutné jedním dechem dodat, že vzniklo v minulém století a od té doby na něj prakticky nikdo nesáhl.
To však neznamená, že by nemělo co nabídnout. Naopak, jedná se o konzistentní systém postavený na promyšlených principech, mezi které (mimo jiné) patří:
Pokud je na obrazovce zobrazen outliner, pro konkrétní objekt, ostatní objekty ho také používají k zobrazení.
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.
Jak jednou pochopíte základy Morphicu (framework ve kterém je dělaný interface), všechno ostatní už se dá relativně intuitivně odvodit.
Například písmeno je objekt. Řádek písmen je složen ze stringu objektů v nějakém layoutu. Řádek sám je v layoutu, který je v layoutu okna. Vše se dá dynamicky měnit a upravovat.
Objekty se chovají jako kdyby to byly skutečné fyzické objekty existující v realitě. Například je možné vyjmout z okna nápis a jen tak jeho kopii umístit do prázdného prostoru. Nejedná se o žádnou nesmyslnou vychytávku - podobně jako fyzické objekty, tak i grafické rozhraní v Selfu je prozkoumatelné a rozebratelné. A podobně, jako u fyzických objektů je možné ho použít ke konstrukci nových rozhraní.
Díky tomu, že jazyk je založený na konceptu prototypů a obrazech paměti, je možné takto složené grafické rozhraní dále používat a postavit z něj třeba aplikaci.
Živost je jednak daná tím, že všechny objekty se překreslují pokud dojde k jejích úpravě, ale také použitím všemožných animací napříč celým uživatelským rozhraním.
Animace jsou většinou skryté na pozadí, například dojde k deformaci okna a vykreslení šedých blobů na místě kudy se pohybuje, čímž je pohybu dodán vjem rychlosti a konkrétního směru. Tyto techniky byly přímo inspirovány animovanými seriály.
Další příklad animace je když dostanete chybovou hlášku, třeba Syntax error a jen jeho box umístíte na plochu. Po čase sám odjede mimo obrazovku, aby nepřekážel.
Osobně mi na tom přijde vysoce zajímavý důraz kladený na možnost uživatele kompletně prozkoumat a podle své chuti modifikovat grafické prostředí. 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á.
Pokud vás principy zaujaly, pro další čtení doporučuji:
Za zmínku stojí také běžně používané nástroje, které jsou k dispozici v Selfové image a repozitáři projektu.
Outliner je ta věc, ve které se dají editovat objekty. Je to v podstatě tabulkové zobrazení jednotlivých metod a properties objektu, které ovšem umožňuje pár věcí navíc:
Ukázka kontextového menu slotu v outlineru:
Shell je jen outliner s předem nastavenými významnými rodičovskými sloty. Pokud otevřete shell pomocí E u standardního objektu, všechny zprávy se vykonávají v kontextu objektu, který outliner reprezentuje. Pokud se jedná o objekt bez rodičovských slotů, tak nemáte dostupné ani běžné objekty, jako true a false. Shell vám nabízí podstatně větší pohodlí v podobě rozšířeného namespace.
Vyvolat se dá kliknutím kolečkem kamkoliv na plochu a vybráním položky New shell.
Core sampler je na pohled taková divná věcička, kterou je možné vyvolat kontextovým menu (pravý klik) skoro z libovolného morphu.
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:
Z tohoto menu je možné okamžitě začít měnit vlastnosti jednotlivých vrstev morphů, upravovat jejich layout, pořizovat kopie a tak podobně.
Pokud vás zajímají detaily, sepsal jsem na tohle téma už kdysi článek Reflexe grafických rozhraní.
Z menu, které se zobrazí kliknutím kolečkem na prázdnou plochu je možné vybrat nástroj factory window. Ten zobrazuje seznam klávesových zkratek, ale i různé druhy morphů připravených k použití. Stačí na ně kliknout a přetáhnout je na prázdnou plochu a můžete začít vytvářet vaše uživatelské rozhraní jejich skládáním.
Za zmínku stojí jakási obrazovka zhruba uprostřed vlevo. Jedná se o prototyp aplikace radarView, který můžete prostě vzít a přetáhnout na plochu.
Poté co ho zapnete vám poskytuje radarové zobrazení celé plochy.
Morph je také možné otevřít z konzole zadáním příkazu do shell outlineru:
desktop w addMorph: radarView
desktop w hands first addMorph: radarView
První příkaz zobrazí morph na kraji obrazovky, druhý příkaz vám ho vloží na pozici kurzoru, takže ho můžete položit kam chcete.
Příkaz je také možné vložit přímo do konzole, ze které Self spouštíte:
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.
Funguje tak, že konkrétní objekty o-anotujeme jako součást nějakého modulu, který je poté možné „zavést“ a „vyvést“.
Praktická ukázka přesahuje rozsah tohoto dílu, jak se to používá je však možné vidět například zde: Exporting Self objects to source files using the Transporter
Vyexportovaný kód je poněkud nečitelný, neboť je uložen jako sekvence direktiv transporteru. Ukázka zde: http_client.self.
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ů.
Kromě těchto nástrojů je možné také ve složce objects/applications repozitáře Selfu najít různé další nástroje, mezi které patří například:
a tak podobně. Projekty jsou veskrze mrtvé a v různé fázi rozdělanosti. Některé fungují, jiné vypadají že byly zaváty časem.
Jednak je tu wikipedie, kde na té české toho zatím moc není, zatímco na té anglické najdete poměrně komplexní úvod včetně mini tutoriálu jazyka:
Jedním z mála koherentních zdrojů dokumentace jsou Self papery, takový archiv vědeckých prací, který je možné najít přímo v repozitáři na githubu:
či v prezentovatelnější podobě na webu:
Pro nováčky je nejvhodnějším zdrojem Self handbook:
Jako úvod do grafického rozhraní je jeden z mála dokumentů použitelný starý tutoriál, který jsem provizorně nahodil zde:
Pokud by měl někdo touhu přečíst celý maillist, tak archiv jsem dal sem:
je tam poměrně hodně informací, ale upozorňuji na to, že čtení může zabrat celé týdny. Pokud by vás zajímal výcuc, tak ho můžete najít na Self blogu:
spolu s dalšími články:
A to je tak nějak vše. Vše ostatní co kde najdete je vesměs zastaralé, neaktualizované a dnes irelevantní.
Mezi zajímavé papery rozhodně patří:
Co bych pak rozhodně nevynechával je:
A toto bylo doslova oči otevírající:
Toliko tedy k prvnímu dílu. V příštích dílech se podíváme na samotný programovací jazyk a standardní knihovnu, filosofické a metafyzické přesahy a tak dál. Celkem by měl vyjít ještě díl, nebo dva, podle toho jak se mi to podaří rozdělit.
Paralelně s tímto seriálem jsem rozjel ještě jeden: Jak se píše programovací jazyk.
Tiskni
Sdílej:
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".