Jak se píše programovací jazyk 1: Motivace

2.2.2019 22:51 | Přečteno: 3315× | Obecné IT | | poslední úprava: 2.3. 02:47

Cca před rokem a něco jsem začal tvořit vlastní programovací jazyk a na obrazu paměti založené interaktivní prostředí ve stylu Smalltalku či Selfu. Zpočátku jsem vůbec neměl tušení jak na to, nakonec jsem však začal řešit jeden problém za druhým a tak vznikl tento seriál.

Seriál jsem pojal tak trochu jako zápisky z cest touto pro mě nepoznanou a exotickou zemí interpretrů a objektových reprezentací. Mým cílem je ukázat čtenářům, že na dosah ruky existují zajímavé cizokrajné krajiny plné skrytých tajemství. Místa tvořená z kódu a logiky, zařící zvláštní vnitřní krásou. Chtěl bych vás inspirovat a podnítit vydat se do nich svou vlastní trasou.

Z tohoto cíle plyne omezení; seriál není průvodcem. Není to mapa, učebnice, či ukázka jak to správně dělat. Je to cestopis. Pracuji jako programátor v Pythonu, čímž byla do velké míry definována moje konkrétní cesta. Plně uznávám a respektuji, že ostatní můžou zvolit jinou cestu, či jiná rozhodnutí.

Motivace

Je mi jasné, že hodně lidí teď napadá proč vlastně, k čemu tvořit nový programovací jazyk, proč se vůbec na tuhle cestu vydat.

Mojí motivací je provést experimenty na následující témata:

1. Reprezentace dat objektovým programovacím jazykem, místo datově orientovanými formáty, jako JSON a XML.
2. Na objektových prototypech založené grafické prostředí a jeho vztah a využitelnost k reprezentaci a práci s daty a informacemi.
3. Reflexe. Skrz jazyk, interpreter, ale i grafické rozhraní.
4. Test filosofické koncepce „explicitně strukturovaných dat“.
5. Otestovat některé z myšlenek Engelbarta ohledně práce s infosférou.
6. Vytvořit platformu, na které bych mohl experimentálně otestovat některé z myšlenek Alana Kaye a Davida Ungara.
7. Získat, otestovat a popsat na míru dělané prostředí tight-coupled-loop technologie, kterou popsal J. C. R. Licklider ve své stati Man-Computer Symbiosis.

Výsledky experimentů budou postupně vycházet na mém blogu: Bystroushaak's blog.

Ač to možná bude vypadat na první pohled paradoxně, tak součástí motivace nikdy nebylo tvořit programovací jazyk. Přestože tenhle seriál bude primárně o tomto, cesta kterou jsem se vydal byla diktována tím, že mě v podstatě nezajímala konkrétní implementace, rychlost, nebo praktičnost k běžnému programování. Nechtěl jsem tvořit konkurenci Javy, Pythonu, nebo C. Nešlo mi o iterativní vylepšení existujících jazyků, či o získání co největší trakce, aby se toho chytla komunita.

Moje snažení bylo diktováno výše uvedenými body. Chtěl jsem vyzkoušet jazyk jako na míru dělaný interface ke stroji. Věci zaměřené na průměrný set uživatelů jsou průměrné. Židle dělaná na průměrný zadek bude horší, než židle dělaná přímo na mírů mému zadku a rozměrům. Jazyk formovaný konsenzem desítek a stovek uživatelů bude pro mě osobně v některých ohledech horší (specificky bod 7), než jazyk který si udělám přesně na míru sám, tak abych s ním mohl co nejvíc „srůst“. Podobně jako Terry Davis se svým Temple OS jsem se rozhodl vydat kompletně jiným „pološíleným“ směrem, bez ohledu na to co si myslí a přejí ostatní.

Jako výchozí bod jsem si vzal programovací jazyk a grafické prostředí jazyka Self. Když jsem hledal věc, která by byla co nejpodobnější mé představě, Self byl to k čemu jsem dospěl oklikou přes rebol, lispy a smalltalky.

Self je v jádru podobně jednoduchý jako lisp, akorát místo polí a funkcí používá objekty. Více se o něm můžete dozvědět v paralelně vycházejícím seriálu o něm: Prostředí a programovací jazyk Selfu (díl první; prostředí).

Proč to není sebevražda

Originální Self je velký. 114 tisíc řádků C++ kódu a cca 350 tisíc řádek Self kódu (serializovaný výstup, reálně jich bude míň). Jak bych tomuhle mohl konkurovat?

Self byl v době vzniku původně výzkumný projekt. To znamená, že je tam všechno možné. Garbage collector, JIT. Různé experimenty ohledně (v té době průlomového) vývoje na poli kompilátorů a interpretrů, ale i grafického rozhraní.

Od začátku mi bylo jasné, že nechci psát vlastní interpreter na zelené louce. Přemýšlel jsem, jak kód transpilovat pro existující virtuální stroje, které používá například Java, C#, Python, Smalltalk nebo Lua. Ideálně tak, abych nemusel řešit garbage collector, ani JIT, což jsou složité věci, které stejně lépe nevymyslím.

Pokud by kód mého jazyka běžel nad některým z těchto prostředí, získal bych zároveň automaticky výhodu jejich standardní knihovny, což by mi ušetřilo další desítky tisíc řádků kódu a vynalézání věcí, jako je součet dvou velkých čísel.

Tím se celá snaha smrskla v podstatě na Lexer, který jednotlivé prvky jazyka rozřeže na pole, Parser, který z toho potom sestaví objektový strom v paměti (AST), což se dá poměrně jednoduše symbolicky vyhodnocovat (s tím mám zkušenosti z toho mého lispu) a tím i snadno debugovat. Dál taky "kompilátor" do bytecode cílového prostředí, což nemusí být nic moc fancy. Prostředí se ideálně postará i o JITování, a tedy smysluplně rychlý běh. Navrch pak musím přidat nějakou standardní knihovnu, ta se ale může do velké míry opírat o prostředí interpretru, vlastní objektový model, který bude stejný jako v Selfu (= jednoduché prototypy), grafické rozhraní, které nezaložím na prehistorické verzi Xlibu, ale na něčem modernějším, a způsob ukládání a načítání image.

Pořád hodně práce, ale signifikantně méně, než kdybych to psal celé odznova.

Založil jsem si na to poznámkovou nodu a pár týdnů prováděl výzkum. Hledal jsem jednak tutoriály, dokumentace a různé projekty na githubu. Protože Self je podobný Smalltalku, měl jsem dobrý výchozí bod kde začít.

Postupně jsem vyloučil jako cílovou platformu Luu i JVM. Hledáním jsem narazil na RPython, ve kterém je psán projekt Pypy. Když jsem přečetl zdroje jako Building an Interpreter With RPython, How to Build a High-Performance VM for Squeak/Smalltalk in Your Spare Time a How to get a JIT Compiler for Free: Implementing SOM Smalltalk with RPython and Truffle, které popisují stavbu interpretrů v pythonu s velmi dobrými zkušenostmi, měl jsem jasno. Některé z těch interpretrů navíc byly Smalltalk, či od něj odvozené jazyky, od čeho je k Selfu jen kousek. Navíc jsem v Pythonu zdaleka nejzkušenější, programuji v něm každý den už celé roky a těžko mě v něm něco překvapí. Rozhodně lepší, než cílit třeba na JVM a psát to celé v Javě.

Jako inspirace mi pak sloužily projekty:

• https://github.com/SOM-st/RPySOM
• https://github.com/HPI-SWA-Lab/RSqueak
• https://github.com/joshsharp/python-braid/
• https://github.com/Julian/BuildingAnInterpreter
• https://github.com/darius/tinyhiss
• https://som-st.github.io/

RPython

RPython je omezený subset jazyka Python vytvořený autory alternativního python interpretru pypy právě za účelem snadné tvorby interpretrů, kde se za vás postarají o ty opravdu složité části. Na vás pak je napsat jazykový frontend, vymyslet si objektový model a dodat uživateli nějakou standardní knihovnu ve vašem jazyce. Jako bonus získáváte state-of-the-art JIT a kompilaci do C.

Alternativně řečeno: RPython vám dovolí podvádět. V podstatě vám umožňuje vyhnout se vší těžké práci.

Pokud bych psal akademický projekt, nebo prováděl výzkum na poli objektových modelů, či JIT kompilátorů, asi bych si to chtěl udělat po svém. Ale jak už jsem psal na začátku, mým cílem nikdy nebylo vytvářet si vlastní programovací jazyk. Chtěl jsem systém. Potřebuji nástroj, ve kterém budu tvořit. Dělat si vlastní programovací jazyk je pro mě spíš opruz, než co jiného. Překážka na cestě, ne cíl.

RPython má oproti standardnímu několik omezení. Například nejde mixovat datové typy ve standardních kontejnerech (pokud dáte do pole int, už tam nemůžete dát str). Taky nefunguje spousta modulů ze základní knihovny. Přesto se však stále jedná o docela vysokoúrovňový a relativně pohodlný jazyk.

Pokud vás zajímají detaily, na rootu o tom vyšel docela hezký seriál: https://www.root.cz/clanky/rpython-prekvapive-vykonny-dialekt-pythonu-na-nemz-je-zalozen-pypy/

Pokračování

V příštím díle se podíváme, jak v něm napsat lexer, což bude následováno dílem o parseru, specifikách RPythonu, objektovém modelu, virtuálním stroji a kompilátoru syntaktických stromů do bytecode.

       

Komentáře

[.]

Jaké důvody jsi měl pro opuštění lispu?

[Bystroushaak]

V podstatě ty že jsem chtěl prostředí, ne jazyk. A lisp má jako prostředí afaik jen Generu, která ale umřela už někdy před 20+ lety a emacs, který vůbec není tím co bych chtěl a potřeboval (znám pár lidí co ho používají a vedl jsem s nimi na tohle téma extenzivní rozhovory).

Další věc je, že mi hodně jde o datový formát. Abys pochopil co myslím, tak to chce ideálně chápat Rebol, kde jazyk je zároveň datový formát i programovací jazyk. Je to v podstatě inverzní myšlenka k XML, kde třeba XSLT je jazyk vyrobený v datovém formátu. Lisp se takhle sice taky dá použít, ale má to moc málo dimenzí aby to byl pohodlný datový formát; představ si jak pohodlný by byl třeba JSON, kdybys tam měl jen pole, bez slovníků.

[deda.jabko]

kde jazyk je zároveň datový formát i programovací jazyk

Nevim, jestli muze byt neco vic zaroven datovy format i programovaci jazyk nez Lisp.

Lisp se takhle sice taky dá použít, ale má to moc málo dimenzí aby to byl pohodlný datový formát; představ si jak pohodlný by byl třeba JSON, kdybys tam měl jen pole, bez slovníků.

Technicky to neni problem, staci si upravit reader a muzes mit, cokoliv si budes prat. Pokud chces nejakou beznou a bohatsi syntaxi, da se inspirovat u Clojure (viz EDN).

[.]

Clojure není dobrý lisp a hackovat reader není dobrá praktika!

[deda.jabko]

Dekuji za hodnotny a peclive vyargumentovany prispevek do diskuze.

[Bystroushaak]

Nevim, jestli muze byt neco vic zaroven datovy format i programovaci jazyk nez Lisp.

Tak třeba zrovna ten Rebol.

[.]

A nešlo by vlastní prostředí udělat v lispu snadněji? Kdysi jsem zkoušel napsat si vlastní lisp a byl jsem šokován tím jak snadné to bylo. Parser byl na pár řádcích (50) a pak už jen implementace pár základních forem a zbytek jazyka jsem udělal pomocí maker už v samotném lispu.

Dovedu si představit že vlastní prostředí pro vývoj image a zároveň exekuce programů by šlo udělat s podobnou lehkostí. Koneckonců, jak smalltalk tak i lisp znají techniku obrazů a není to podle mne náhoda. Myslím že jazyky se silnou reflekcí k tomu mají tendenci konvergovat.

Lisp může sloužit i jako dobrý datový formát, samozřejmě, chtělo by si to vylepšit makrama tak abys měl pohodlnou notaci map a setů. Možná jen nechápu co přesně hledáš, ale lisp podle mne můžeš ohnout tak moc, že už to ani nebude lisp.

Je mi jasný, že asi není dobrý nápad ti rozmlouvat cestu kterou ses vydal a nepochybně investoval spoustu času. Ber to jako evangelizační snahu nadšeného lispera...

[Bystroushaak]

A nešlo by vlastní prostředí udělat v lispu snadněji? Kdysi jsem zkoušel napsat si vlastní lisp a byl jsem šokován tím jak snadné to bylo. Parser byl na pár řádcích (50) a pak už jen implementace pár základních forem a zbytek jazyka jsem udělal pomocí maker už v samotném lispu.

Já jsem si ho napsal taky, takže vím co myslíš.

Dovedu si představit že vlastní prostředí pro vývoj image a zároveň exekuce programů by šlo udělat s podobnou lehkostí. Koneckonců, jak smalltalk tak i lisp znají techniku obrazů a není to podle mne náhoda. Myslím že jazyky se silnou reflekcí k tomu mají tendenci konvergovat.

Asi by to šlo. Self mě v tomhle víc motivoval, neboť to prostředí v něm do velké míry je, i když neudržované a v mnoha ohledech nedotažené. Generu jsem chtěl párkrát zkusit, ale nikam to nevedlo, možná bych se měl zase podívat po emulátorech.

Lisp může sloužit i jako dobrý datový formát, samozřejmě, chtělo by si to vylepšit makrama tak abys měl pohodlnou notaci map a setů. Možná jen nechápu co přesně hledáš, ale lisp podle mne můžeš ohnout tak moc, že už to ani nebude lisp.

Viz ten rebol. To je v podstatě lisp s hodně suggar candy parserama, které si můžeš i bezbolestně definovat sám. Úplně mi to nevyhovovalo.

[kralyk z abclinuxu]

ale lisp podle mne můžeš ohnout tak moc, že už to ani nebude lisp

Begs the question: K čemu je potom dobré do toho vůbec tahat lisp.

[.]

Nechápu otázku. Pomocí reader maker můžeš do lispu embedovat cokoli, ale už to nebude mít vlastnosti lispu. To jsem tím myslel.

[kralyk z abclinuxu]

No přijde mi, že když chci vytvořit jazyk, který není lisp, tak nemá moc smysl použít na to lisp...

[little-drunk-jesus]

No tezko rict - co treba Racket je Lisp dost :). Tezko rict jak to porovnat RPython, ktery neznam, ale obecne se s tim hralo hezky.

[JS1]

Podle mne ma. Zrovna minuly tyden jsem se o tom bavil s kolegou. Kdybych ja psal programovaci jazyk, tak se v prvni fazi pokusim vyhnout vlastnimu lexeru a parseru, protoze syntaxe je druhotny problem.

Dulezitejsi je IMHO semantika a tak je praktictejsi zapsat primo AST v uz existujicim jazyce. Tim existujicim jazykem muze byt temer cokoli, ale nektere jsou na to z podstaty veci vhodnejsi (ja bych pouzil Haskell, ale lze velmi dobre pouzit i jakykoli druh Lispu; lze dokonce pouzit i treba C++).

A pokud se pouzije primo Common Lisp, da se znacne experimentovat i syntaxi (pomoci reader maker), je-li to zadouci.

[Bystroushaak]

Kdybys chtěl dělat vlastní jazyk, tak v první fázi neděláš jazyk. Je potom otázkou, jestli se vůbec o jazyku ještě bavit a nenazývat to třeba systémem pro evaluaci struktur.

[JS1]

Ale o to prave jde, ne? Jadro noveho jazyka je prave v interpretru.

[Bystroushaak]

Jádro určitě, ale ne celá podstata. Jednoduše protože jádro může být sebelepší, přesto pokud bude mít shitózní syntaxi, tak to nikdo nebude chtít používat. Jazyk prostě není jen VM, jde to ruku v ruce.

Ostatně hezky to ukazuje třeba python, kde je interpretací přehršel, včetně třeba toho pypy, které funguje interně úplně jinak, než cpython. Přitom je to všechno pořád stejný jazyk. Nedá se tedy říct, že by VM byla nějak definující. Ostatně já už od začátku počítám s tím, že moje VM bude v některých ohledech objektivně horší*, než třeba existující VM Selfu, přestože jazyk bude skoro stejný.

*Například asi bude pomalejší, 2-10x náročnější na výkon a rozhodně minimálně 10x víc paměťově náročnější. V jiných ohledech zase snad bude objektivně lepší, třeba v pochopitelnosti**, rozšiřitelnosti, náročnosti vývoje, integrovatelnosti do dalších projektů (rád bych se dostal někam ala lua) a tak podobně. Asi bych to měl někde obecně popsat.

** Mým cílem je nepřesáhnout 10k řádků python kódu VM. Zatím se lexer, parser, kompilátor, VM, disassembler, hromada primitiv a testů vejdou do 4k2 řádků.

[deda.jabko]

shitózní syntaxi, tak to nikdo nebude chtít používat.

Syntaxe je jenom mala cast jazyka, semantika (a vyjarovaci schopnosti jednotlivych primitiv jazyka) je to, co jazyky hlavne odlisuje. LISP a Scheme maji stejnou syntaxi, ale semantika je jina. Z druhe strany, C i Java maji velice podobnou syntaxi, presto vyjadrovaci schopnosti jsou uplne jine.

Jednoduše protože jádro může být sebelepší, přesto pokud bude mít shitózní syntaxi, tak to nikdo nebude chtít používat.

Ono, i kdyz budes mit jazyk s hezkou syntaxi a nebudes mit kolem toho pouzitelny tooling, tak to nebude pouzitelne tak jako tak. Takze pokud muzes pouzit nastroje pro hostitelsky jazyk, je to podstatne plus.

[Bystroushaak]

Syntaxe je jenom mala cast jazyka, semantika (a vyjarovaci schopnosti jednotlivych primitiv jazyka) je to, co jazyky hlavne odlisuje. LISP a Scheme maji stejnou syntaxi, ale semantika je jina. Z druhe strany, C i Java maji velice podobnou syntaxi, presto vyjadrovaci schopnosti jsou uplne jine.

Pravda.

Ono, i kdyz budes mit jazyk s hezkou syntaxi a nebudes mit kolem toho pouzitelny tooling, tak to nebude pouzitelne tak jako tak. Takze pokud muzes pouzit nastroje pro hostitelsky jazyk, je to podstatne plus.

Jasně no. Jak jsem psal, mým cílem není mít něco úplně praktického v běžném slova smyslu jak vnímáme jazyky. Tohle je jádro pro systém, které chci použít k různým experimentům, například na tom založit osobní wiki, nebo "objektovou databázi".

Cílem je pro mě to experimentování, ne rozšíření mezi běžné developery. Z toho mimo jiné plyne například že tooling a praktičnost tolik neřeším, stejně jako pokud by někdo přidal nějakou super feature, která ale půjde proti tomu experimentování, tak mu to prostě nezamerguju.

[JS1]

Ale ja nemluvim o VM, ale o semantice toho jazyka. To ze mas VM je spis implementacni zalezitost. Podstatne je, jak se treba chovaji promenne a scopes atd.

Jak sam pises, v podstate to bude Self. Pak mi unika, proc prvni verzi nepsat primo v Selfu. V cem ma byt semantika tveho jazyka jina?

[JS1]

Vys deda.jabko to napsal dobre - semantika je v podstate chovani jednotlivych primitiv jazyka, tedy tech casti jazyka, ktere nemuzes napsat v nem samotnem.

[Bystroushaak]

Jak sam pises, v podstate to bude Self. Pak mi unika, proc prvni verzi nepsat primo v Selfu. V cem ma byt semantika tveho jazyka jina?

O tom budou další díly toho druhého seriálu. Self je v dost špatném stavu a komunita kolem něj je hodně akademicky zaměřená. Víc je třeba zajímá funkce kompilátoru, než podpora unicode zobrazování. A většína kódu je slitek C++ a Self bindigů do toho C++, takže co se mě týče, tak snaha tam třeba přidat podporu unicode výstupu byla vyhodnocena jako složitější, než si napsat vlastní jazyk, do kterého mi navíc nikdo nebude kecat.

[kralyk z abclinuxu]

Ale o to prave jde, ne? Jadro noveho jazyka je prave v interpretru.

Za mě ano, nicméně vlastnosti toho interpreteru a vlastně i syntaxe nejsou nepodstatné. Z mého pohledu ta volba toho lispu sice dává nějaké možnosti, ale zároveň je omezující (jak co do vlastností tak i syntaxe). Ta omezení dávají smysl když člověk dělá lisp/lisp-like jazyk, ale když chce dostatečně jiný jazyk, IMHO už to smysl až tak nedává.

Ale nevim, jaký plány/požadavky má Bystroušák.

Just my $.02

[deda.jabko]

Z mého pohledu ta volba toho lispu sice dává nějaké možnosti, ale zároveň je omezující (jak co do vlastností tak i syntaxe).

Muzes byt trochu konkretnejsi?

Syntaxe LISP-like jazyku odpovida AST, takze pokud chces hezkou syntaxi, staci ti udelat jednoduchy prekladac do s-vyrazu/AST, coz neni tak narocny krok.

Co se tyce vlastnosti, zaklad Lispu/Schemu ma vyjadrovaci schopnosti, ktere umoznuji velice jednoduse vybudovat konstrukty ostatnich jazyku, vcetne toho OOP.

[xkucf03]

Syntaxe LISP-like jazyku odpovida AST, takze pokud chces hezkou syntaxi, staci ti udelat jednoduchy prekladac do s-vyrazu/AST, coz neni tak narocny krok.

Tohle dělají v Guile – výchozí je Scheme, ale dá se přepnout (dokonce za chodu) i na JavaScript nebo EmacsLisp a v plánu jsou i další jazyky. Ale jak náročné to je, nevím – úplně triviální to asi nebude, jinak by asi těch jazyků bylo podporovaných už plno.

[kralyk z abclinuxu]

Muzes byt trochu konkretnejsi?

No, z mého pohledu exekuční/evaluační model lispu má omezení v tom, že je relativně daleko od železa a nemapuje na něj úplně pohodlně. Koneckonců, v tomhle je to gro komplexních implementací jako CL nebo Clojure. Tj. záležitosti jako výkon a FFI bych na té cestě přes Scheme viděl jako potenciálně problematičtější.

Se syntaxí je to podobné - běžné syntaxe nemusí pohodlně mapovat na lisp AST. Samozřejmě se to dá překonat, ale... viz níže.

Ty vlastnosti toho RPythonu jsou takové jaká jsou ne náhodou, ale mimo jiné i z těhle důvodů.

Syntaxe LISP-like jazyku odpovida AST, takze pokud chces hezkou syntaxi, staci ti udelat jednoduchy prekladac do s-vyrazu/AST, coz neni tak narocny krok.

Mně tohle přijde trochu v duchu "Your scientists were preoccupied...". Ano, můžeš (a asi celkem snadno) udělat překladač čehokoli do lisp AST a následně použít komplexní lispovou implementaci, aby ti to přechroustala do něčeho relativně stravitelného pro stroj, ale proč to dělat? U toho RPythonu mi přijde, že je na obou koncích méně daleko.

Samozřejmě pypy taky není úplně jednoduchá záležitost, ale stále mi to přijde jako menší 'zacházka' a třeba to FFI v tom asi půjde celkem snadno (což je z mé strany jen odhad - můžu se mýlit).

[Bystroushaak]

Samozřejmě pypy taky není úplně jednoduchá záležitost, ale stále mi to přijde jako menší 'zacházka' a třeba to FFI v tom asi půjde celkem snadno (což je z mé strany jen odhad - můžu se mýlit).

Ještě jsem ho nedělal, ale mělo by jít.

[deda.jabko]

No, z mého pohledu exekuční/evaluační model lispu má omezení v tom, že je relativně daleko od železa a nemapuje na něj úplně pohodlně.

Toto vidim jako ciste hypoteticky problem. CPython nebo PHP jsou zoufale pomale, mnohdy na urovni primocare implementace Lispu (nekdy i pomalejsi, osobne overeno) a presto to nebrani(lo) v jejich pouzivani na produkcnich vecech, nota bene pak na hobby projektech.

Se syntaxí je to podobné - běžné syntaxe nemusí pohodlně mapovat na lisp AST. Samozřejmě se to dá překonat, ale... viz níže.

Opet hypoteticky problem. To mapovani syntaxe na AST je z principu trivialni, a pokud neni, tak je takove mapovani z principu trivialni, protoze pokud mas slozitejsi konstrukt, muzes ho namapovat na vlastni typ uzlu/makro a o expanzi se uz postara Lisp. Zadna komplexita zatim neni.

následně použít komplexní lispovou implementaci, aby ti to přechroustala do něčeho relativně stravitelného pro stroj, ale proč to dělat? U toho RPythonu mi přijde, že je na obou koncích méně daleko.

Viz vyse.

Samozřejmě pypy taky není úplně jednoduchá záležitost, ale stále mi to přijde jako menší 'zacházka' a třeba to FFI v tom asi půjde celkem snadno (což je z mé strany jen odhad - můžu se mýlit).

FFI neni problem ani u hobby Lispu.

[kralyk z abclinuxu]

Toto vidim jako ciste hypoteticky problem. CPython nebo PHP jsou zoufale pomale, mnohdy na urovni primocare implementace Lispu (nekdy i pomalejsi, osobne overeno) a presto to nebrani(lo) v jejich pouzivani na produkcnich vecech, nota bene pak na hobby projektech.

No tak do CPythonu nebo PHP bych osobně v tomto případě taky nešel, ale máš pravdu, že hypotetické to je, protože moc neznám Bystroušákovy požadavky.

Ještě bych (stále v rámci té hypotetičnosti) vedle RPythonu uvažoval např. o LuaJIT nebo webAssembly.

[Bystroushaak]

LuaJIT

To jsem si původně myslel že bude asi nejlepší, ale nenašel jsem k tomu vůbec žádnou dokumentaci a kompilovat to přímo do lua jazyka, jak to dělá spousta projektů z Languages that compile to Lua mi přišlo jako hrozná prasárna.

RPython sice možná nemá nejlepší dokumentaci, ale alespoň nějakou + jsou v tom udělané praktické projekty, které fakt fungují (pypy a ty různé smalltalky) a které měly ucházející papery se zkušenostmi.

webAssembly

Rpython by mohl časem cílit i na tenhle backend.

[xkucf03]

Výsledky experimentů budou postupně vycházet na mém notion.so blogu: Bystroushaak's blog

Proč zrovna tam? Vždyť sám píšeš:

Sorry, no RSS yet, but I am working on it (one of the many reasons why notion.so sux).

A spousta podobných služeb skončila, odkazy umřely, obsah zmizel… Máš přece vlastní doménu, máš Abíčko, můžeš to dát na GitLab a nechat zbytek světa, aby to kopíroval atd.

[.]

Na prvních řádkách se píše že to je jen temp solution a pracuje na vlastní platformě.

Ale medium by podle mne bylo lepší. Jeho pod projekt hackernoon má velkou oblíbenost a velkou návštěvnost.

[Jendа]

Já mám Medium spojené s popupy „Pardon the interruption.“, toolbary přilepenými nahoře a dole, které nejdou dát pryč, a jejich vlastními pokusy o „zlepšení“ čitelnosti manipulací sazby, fontu a barev, ačkoli já jsem přece ten, kdo ví nejlíp, co se mi nejlépe čte, a mám přesně podle toho svůj prohlížeč nastavený.

V tomhle je prostě nejlepší AbcLinuxu - text je prostě v <p> tazích bez jakéhokoli specifikovaného formátování a každý má nastaveno jak se mu líbí.

[Bherzet]

+1

[Bystroushaak]

Příloha:

• notion_kanban.png (410465 bytů)

Proč zrovna tam?

Protože jsem pragmatik. Původně jsem chtěl notion.so jen vyzkoušet, když mi o něm nadšeně vyprávěl brácha. Zkouším tak nějak všechny možné osobní wiki, protože všechno má nějaké nedostatky a chtěl jsem vidět klady a zápory všemožných přístupů předtím než se pustím do vlastního řešení.

Takže jsem se zaregistroval, chvíli to zkusil používat, moc se mi to nelíbilo a lehce jsem to hejtoval (javascript, hipsteřina, uzavřenost, viz Disadvantages of notion.so). Pak jsem si asi po týdnu vzpomněl na můj starší blog Kübler-Rossová v IT, který jsem napsal abych právě popsal přesně tenhle pocit, kdy si myslím že nějaká technologie je sračka, přestože někdo jiný, o kom vím že není debil, o ní tvrdí, že je fajn. Upravil jsem tedy své očekávání a zkusil to použít bez předsudků a vcelku rychle jsem zjistil, že co se psaní týče, tak v tom mám větší celkovou produktivitu než třeba v CherryTree, které používám běžně na všechno možné.

Ve zkratce tedy; Má to samozřejmě spoustu nevýhod, ale dobře se mi v tom píše. A relativně pohodlně se z toho dostávají věci ven. Nodu vyexportuju, uložim jí jako .zip s kopou obrázků a .md souborem obsahující text v markdownu. Ten poté zkonvertuji pandocem do html, vyčistím kraťoučkým scriptem který odstraní většinu atributů co tam pandoc nacpal a to je všechno. Práce asi na minutu.

Oproti tomu v CherryTree se mi píše asi o stupínek lépe (přeci jen je to desktopová aplikace s podstatně lepší odezvou + mám rád ten jeho wysiwyg), ale neumí žádné pokročilé formátování. Vložit do něj jen pitomý obrázek je problém, protože interní rich text ho například downscaluje a už z něj nikdy nevytáhneš co jsi chtěl. A třeba dostat z CherryTree je totální peklo, na které mám napsaný konverzní program, který po 75 commitech pořád nezvládá všechno, protože interní zkurvenost rich textu co CherryTree používá je naprosto neuvěřitelná a nepopsatelná. To po mě například vyžaduje vcelku náročný postprocessing, kde není výjimkou, že konverzí článku jako je ten první díl o Selfu bych strávil klidně 30+ minut ručních editací HTML.

Notion oproti tomu taky umí všechno možné formátování, třeba tu vedlejší sérii článků o Selfu jsem psal v kanban boardu, kde každý štítek v něm byla samostatná textová noda (viz příloha) obsahující jednu kapitolu. Výsledek jsem pak vzal, naházel pod textovou nodu a dal to celé dohromady do článku. Dá se v něm inlinovat videa, různé další soubory, celé stránky.

Tohle má hodně blízko k systému, který bych chtěl vybudovat s tím svým programovacím jazykem a musím říct, že to prostě vede k větší produktivitě. A jak jsem psal na začátku, snažím se být pragmatik, tzn pokud má něco větší efektivitu, je to měřitelně lepší a výkonnější a jsi v tom produktivnější, tak je hloupost a sebe-škodění to nepoužívat.

Ostatně třeba zrovna linux taky nepoužívám protože by mi nějak extra vyhovoval, ale protože prostě není nic lepšího. Kdyby bylo, tak ho zahodím a utíkám až mi vlajou vlasy :]

A spousta podobných služeb skončila, odkazy umřely, obsah zmizel… Máš přece vlastní doménu, máš Abíčko, můžeš to dát na GitLab a nechat zbytek světa, aby to kopíroval atd.

Pozor, tady je třeba rozlišit dvě věci. Mám vlastní doménu, ale nemám momentálne vlastní publikační systém. Už mnoho, mnoho let sbírám podněty a todo body a nápady, jak ho vytvořit a vím úplně přesně co chci. Co se mě týče, tak ať už tedy udělám cokoliv kromě toho systému, tak to vždycky bude náhražka, suboptimální řešení, které mě bude v něčem srát. Jestli teda používat github, nebo třeba notion.so je mi docela jedno.

Co se týče druhé věci, tak nikdy bych nepoužíval službu, nad kterou nemám kontrolu alespoň ve smyslu že mám všechna data. A zrovna z toho notion.so si dělám pravidelné úplné exporty všech dat v markdownu, ale nedávno se mi navíc podařilo reverzovat jejcih API, takže si sahám přímo na různé javascriptové objekty, které to už chce jen ztransformovat do HTML / whatever.

[dad]

vsimas si, jak jsi cim dal tim ve svych prispevcich vulgarnejsi? Snad jsi v poradku, vidavam to jako prvni symptom upadku ducha

[ada]

Tak to ani nechci vidět, jak bys diagnostikoval tohle

[Radovan]

Jako mírnou nasranost. A tohle znáš?

[Bystroushaak]

vsimas si, jak jsi cim dal tim ve svych prispevcich vulgarnejsi? Snad jsi v poradku, vidavam to jako prvni symptom upadku ducha

A co že ty máš najednou starost o stav mého ducha? :)

Jinak osobně bych řekl, že moje používání sprostých slov je na úplném historickém minimu, myslím že kdybys fakt udělal komparativní analýzu, tak bys nestíhal čumět. Například se mi skoro podařilo eliminovat slovo mrdka používané jako úroveň kvality. Například Outlook jako mrdka shnilá, mrdka plesnivá, mrdka zlá a prohnaná. Podčůráčí a smažené řitní věnce už taky nerozhazuju na počkání a že je někdo kvazidebilní heptačůrák jsem taky neřekl ani nevím jak dlouho. A třeba fekální poezii jsem snad neskládal* od hejtu co jsem sem psal.

Takže za mě v poho ;)

*;

V reakci na úpadek ducha,
stříkám mrdku do dadova ucha.

Součástí jazyka od dávné doby,
je užití nadávek k ventilení zloby.

Místo symptomů hledej klady,
nebudem muset psát sračky tady.

[Radovan]

Zajímavé čtení, jsem zvědavý co se z toho nakonec vyvine. Možná se jednou pokusím o něco podobného, líbil by se mi jazyk bez příkazů a dalších zbytečností...

[Odin1918]

Nechapu, jak nekdo muze pojmenovat svuj projekt ci vytvor 'pypy'. S tim bych asi nemohl delat. Asi bych stale mel pred ocima ty tuny plenek, ktere nam prosly rukami.

[Bystroushaak]

Tak tuhle asociaci fakt nechápu.

[Bherzet]

Prostě se jim posrávalo dítě při sledování Pypy dlouhé punčochy.

[marek_hb]

můj odhad - Odin mluví na dítě anglicky a nevěřil bys, jak si dítě dokáže slova jako pee pee přetvořit k jazyku svému....

[Bystroushaak]

Tak co jsem já kdy slyšel lidi to vyslovovat, tak to nebylo jako pee pee, ale jako páj páj, což snad pro exkrementy nikdo nepoužívá. Viz třeba hned začátek How the PyPy JIT works.

[Odin1918]

https://de.m.wikipedia.org/wiki/Pipi

[_]

jawohl, nazisprache

[Odin1918]

Proc? Nemecky hovoril i Karl Marx, Albert Einstein i Wenzel Jaksch. Vidis mezi nimi nacistu? Ani omylem. Prestan prosim hanobit Nemcinu takovymi nalepkami. Jazyk nemuze za nektere sve uzivatele.