Fórumok
Egy új, forradalmi nyelv van születőben, a Unison.
A forradalmi ötlet az, hogy az egyes definíciókat nem névvel azonosítjuk, hanem az absztrakt szintaxis fájuk hash-ével.
Ennek nagyon érdekes következményei vannak:
- Az elosztott rendszerek létrehozása és kezelése rendkívüli módon egyszerűsödik. A microservice architektúra számos hátránya eltűnik.
- Nincs build idő, vagyis gyakorlatilag nulla. Az erősen statikusan típusolt nyelveknél elég sokáig tart egy nagyobb alkalmazás buildelése. Itt gyakorlatilag nincs build, mivel az egyes definíciók ellenőrzés és átalakítás után, egyből bekerülnek a közös kódbázisba, ahol azonnal használhatóvá válnak.
- Nincs függőségi konfliktus. Egy-egy definíciónak tetszőleges sok verziója létezhet és futhat egymás mellett.
- Típusolt, tartós tárolás. Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani, gyakorlatilag az adott adat közvetlenül tárolható, akár elosztott rendszerben is.
- Gazdagabb kódbázis eszközök. A Unison kódbázis egy megfelelő adatbázis, amely ismeri minden tárolt dolog típusát, tökéletes fordítási gyorsítótárral, tökéletes tudással rendelkezik a függőségekről, a típusalapú keresés indexeiről és még sok másról. Ez lehetővé teszi számunkra, hogy egyszerűen készítsünk sokkal gazdagabb eszközöket a böngészéshez és a kóddal való interakcióhoz. Gyakorlatilag nem szükséges IDE, egy egyszerű szövegszerkesztővel is az IDE szolgáltatások elérhetőek, sőt még annál többek is.
- Struktúrált refaktorálás. Mivel a kódbázisban eltárolva van az összes függőség, strukturált módon, így segítséget kapunk a refaktorálás folyamatán, hogy mikor mit módosítsunk. Plusz előny, hogy a kódbázisunk folyamatosan futtatható állapotban van, sosincs törött állapotban.
Ui.:
Ebből a videóból sokkal jobban megérthető az ötlet és a működése:
"Unison: a new distributed programming language" by Paul Chiusano
Hozzászólások
Ismertetők:
A look at Unison: a revolutionary programming language
Unison: program differently by Adam Warski | Lambda Days 2023
Hát... ez max azoknak a haskel rajongóknak lesz érdekes, akik nem akarnak on-premise felhőt. :)
A Haskell rajongók meg azért nem fogják használni, mert nem teljesen pure ;-)
Akkor halott projekt. ;)
Az "érdekes következmények" tele vannak ellentmondásokkal és bullshittel:
Nincs build idő, vagyis gyakorlatilag nulla. vs. az egyes definíciók ellenőrzés és átalakítás után - ez utóbbi talán nem idő?
Nincs függőségi konfliktus. vs. Struktúrált refaktorálás.
Egy-egy definíciónak tetszőleges sok verziója létezhet és futhat egymás mellett. vs. segítséget kapunk a refaktorálás folyamatán, hogy mikor mit módosítsunk - de hát minden függőség eleve benne van, akkor minek refaktorálni? Ha meg a logikai réteget kell refaktorálni, abban meg úgysem tud segíteni a típusadatbázis.
Típusolt, tartós tárolás. Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani, gyakorlatilag az adott adat közvetlenül tárolható, akár elosztott rendszerben is. - konkrét bullshit. Lássuk, hogy olvas be valaki egy GIF-et például így, átalakítás nélkül.
Ez egy kamu, nem egyéb parasztvakításnál. Hozzáértő szem elsőre kiszúrja, az AST előállítása is része a build időnek, aztán meg akármit varázsolsz, csak kell egy kódgenerátor is, ami az AST-t natív binárissá alakítja, vagy egy interpreter, ami értelmezi. Önmagában az AST nem is futtatható program.
Ha valamiről semmi tudásod nincs, akkor nem javasolt határozott véleményeket megfogalmazni. ;-)
Azért megpróbálok válaszolni a tévedéseidre.
Igen, idő, de nem build idő. Ahogy az sem build idő, amikor egy forrást feltöltesz forráskezelő (pl. git) tárolóba. Ez pontosan ugyanakkor történik, csak nem forrásként tárolja, hanem szintaxis faként.
Itt nem értem mi az ellentmondás.
Ha az egyik verzió helyett egy másikat akarnál használni. Ilyenkor felsorolja neked az összes helyet, ahol az egyik verzió van használva, illetve ha kompatibilis, akkor automatikusan ki is cseréli a referenciát, ha nem, akkor sorrendbe rakja, hogy mikor mit írjál át.
Nem erről van szó. Arról van szó, hogy van egy adatod, amit el szeretnél tárolni, majd vissza akarod olvasni. Ilyenkor nem kell átalakítanod mondjuk json-ba, letárolni, majd visszaolvasáskor visszaalakítani adatszerkezetté, hanem az adott szerkezetet tárolod el és olvasod vissza pontosan ugyanazt. Ez nem arra való, hogy a külső világgal kommunikálj, hanem csak a belső adatok tárolására, visszaolvasására.
Ez pontosan így van. Jelenleg csak interpreter van, ami értelmezi. Tervben van a binárissá alakítás is, nyilván ott lesz valamennyi build idő is.
LOL, sejtelmed sincs, kivel beszélsz :-D
Ha a forrás ellenőrzése, átalakítása és az AST előállítása belőle nem a build időhöz tartozik, akkor hova? Írtál te már fordítóprogramot? Én igen.
Ezt bármelyik fejlettebb IDE megteszi neked bármelyik programozási nyelv esetén. Ebben semmi forradalmi sincs.
Úgy van. Van egy kép adatom, amit GIF-két szeretnék eltárolni majd visszaolvasni. Hogy akarod ezt megoldani átalakítás nélkül?
Az, hogy az Unison képes egy memdumpot lementeni és visszaolvasni nem nagy kunszt, ezt bármelyik programozási nyelven megteheted és mindenhol piszok gyors. Csak épp ugye a lementett adat használhatatlan bármilyen más környezetben. Ebben sincs semmi forradalmi, már ősidők óta használnak memdumpokat.
Az sem újdonság, hogy közvetlenül az AST-t tárolják, a .pyc fájlok ugye pontosan ezt teszik, binárisan szerializált Python AST fák. Adatok tárolására sem újdonság, a Blender által mentett .blend fájlok lényegében strukturált Python memdumpok például. Semmi forradalmi.
Nem tudtam, hogy Unison szakértő vagy ;-) Ugyanis arról tettél határozott kijelentéseket, pedig láthatóan fogalmad sincs róla, miként működik.
Ugyanoda, ahová a git-re felrakáskor futó ellenőrzések tartoznak. Az build idő?
Nem erről van szó még mindig. Arról, hogy kvázi adatbázisba ments dolgokat, amiket aztán kereshetsz, szűrhetsz, visszatölthetsz, ...
Igen, ez nem újdonság. Az az újdonság, hogy ezt egy kódbázisba teszik be, amit a hash-ük azonosít. Így a kódbázisba betevéskor már meglesz az összes függőség, mi mihez, hogyan kapcsolódik. Onnan közvetlenül futtatható, akár távoli gépeken is.
Össze-vissza beszélsz. A gitbe tudsz pusholni build nélkül is, és build-et is tudsz csinálni git push nélkül.
Tipikus babzsákfotelfejlesztő vagy, csak mert a git push során lefuthat egy build, már nem is tudsz különbséget tenni a kettő között.
A forrás ellenőrzése, átalakítása és az AST előlállítása belőle AZ IGEN, az biza build idő, de ennek semmi köze a CI-hez. Mondjuk aki ennyire nincs tisztában az alapfogalmakkal, az nem csoda, hogy bedőlt ennek az Unison bullshitnek.
Adatokról volt szó, nem kódról, de abban sincs semmi újdonság. Ősidők óta a fordítók hash-el tárolják a kód definícióit, DT_HASH már olyan régi, hogy el is avult, manapság már mindenki DT_GNU_HASH-t használ.
Mégegyszer, ebben semmi, de semmi forradalmi újdonság sincs. Csúnyán megvezettek, felültél a bullshitnek.
Azzal egyetértek, hogy kicsit túl van hype-olva, de ettől függetlenül az ötlet (ami nem új, csak újszerűen használva) megold egy csomó problémát.
A fordító csak a saját munkáját könnyíti meg a fejlesztő gépén vagy a ci/cd pipeline rövid életű elemeként, de utána nem kezd vele semmit. Ha jól értem itt mivel erősen kikényszerített módon vagy kötelezve a funkcionális programozás használatára, a kód, a függőség kezelés, a fordítás és a futtatás egysége is a függvény. Emiatt a fordítási idő az egy módosult függvényedre vonatkozik, a push szintén, az artefact feltöltés szintén, a futtatás előtt/alatt letöltött program szintén. Azaz baromi pici immutable komponensek kezelése van végig vezetve az egész láncon, ami tényleg új, ilyet más lépésenként csinál, de egyben nem tudok hasonlóról. Hogy ezzel minden megoldható-e, főleg hatékonyan, az egy jó kérdés. A mellékhatások elkerülése adatok állapotával dolgozó rendszerek esetén kb lehetetlen, így azért sérül a funkcionális programozás ígérete. De ennek ellenére architektúrális szempontból elosztott rendszerek esetén törekedni kell a szabályai betartására az architektúra minden szintjén, különben egy időzített bomba az egész.
Nem jól érted. Ez a nyelv nem is teljesen pure funkcionális. Ez az elv működne bármely más nyelv esetén is.
kontra
Na tessék, egy újabb ellentmondás. Akkor most funkcionális vagy sem?
Funkcionális, de nem teljesen pure funkcionális. Lehet benne nem referential transparent megoldást is írni.
Igen, egyetértek. Nem véletlen, hogy egy csomó IDE és fordítóprogram is tudja már ezt. Nekem is főként a "forradalmi" jelző böki a csőrömet, és nem maga a hash ilyettén használata.
Ezzel is egyetértek. Konkrét összehasonlító mérések kellenének, hogy kiderüljön, lépésenként végrehajtva vagy egyben kezelve jobb-e, megéri-e a hozzáadott bonyolultságot.
Egy kicsit ott sántít szerintem a dolog, hogy mi van, ha több verziót is használ egy függvényből a program, de ez rossz, és a refaktor során egységesíteni kellene. (Tipikus példa, a proggi úgy lett megírva, hogy egy .so X függvényét használja, de az az .so frissül, ezért az új kód már az X függvény új verzióját használja. Ekkor nyilván más a hash, ezért ha "az egyes definíciókat nem névvel azonosítjuk, hanem az absztrakt szintaxis fájuk hash-ével", akkor esély sincs rá, hogy az Unison észrevegye, hogy e kettőt igazából egységesíteni kellene és nem külön tárolni).
Persze lehet nyilvántartani azt is, hogy melyik hash-ből melyik hash lett, de ez olyan bonyolultságot ad, ami miatt nem biztos, hogy megéri: egyrészről itt az összes függőség (saját kódbeli + összes .so) összes függvényének összes history-járól van szó, ami nem kevés és drasztikusan növekedő adatbázist igényel, másrészről kérdéses az implementáció hatékonysága is, azaz vissza az előző ponthoz, konkrét mérések kellenének, hogy megéri-e egyáltalán.
Ezzel is egyetértek. De tovább mennék, nekem a "Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani," bullshit szagúnak tűnik, mert az Unison adatokat nem lehet egy-az-egyben tárolni a már meglévő formátumokban (nincs olyan - és nem is lehet - már létező formátum, amiben lenne helye az Unison specifikus típus kódoknak az értékek mellett, mondjuk egy PNG-ben, WAV-ban stb. így egész biztos lehetetlen a feldolgozás az adatok oda-vissza alakítása nélkül).
Ugyanez igaz az összes már létező erősen típusos nyelvre is, ebben sincs semmi újdonság. Ráadásul nem is egyformán tárolják a típuskódot, lásd pl CPython, WASM ByteArray stb. stb. stb. Elég csupán csak arra gondolni, hány, de hány különböző módon tárolják a string típust a memóriában (akár egy nyelven belül is) és hogy hogyan vannak ezek tárolva a fájlokban. Az átalakítás csak akkor úszható meg, ha memdump-ot használsz és semmilyen más környezetben nem akarod feldolgozni az így mentett adatokat. Minden más esetben elkerülhetetlen az oda-vissza átalakítás, tehát ez az ígéret biztosan hazugság.
Idézném bazsot:
Ha arra se veszed a fáradtságot, hogy a magyarázataimat megértsd, pláne azt nem, hogy utánanézz mi is ez valójában és miként működik, akkor kár személyeskedned, mert csak magadat égeted.
Öcsém, miről beszélsz amikor még a build-et sem vagy képes megkülönböztetni a CI-től? A magyarázataid úgy rosszak, ahogy vannak, tele vannak tévedéssel és önellentmondásokkal. Gondolkodj el ezen kicsit.
Az a probléma, hogy az Unison mélyebb ismerete nélkül is vannak problémák a magyarázataiddal, és nem válaszolod meg a kérdéseket/oldod fel az ellentmondásokat, hanem megsértődsz. Értem, hogy ez természetes reakció egy általad kedvelt valaminek a bántására, de biztos, hogy nem professzionális. Ha az Unisont nem is láttuk még, a szálban mindenki dolgozott már több programnyelvvel, több különböző adatbázissal, több különböző fájlformátummal. Ha ebből indulsz ki, és nem abból, hogy csak te lehetsz a helikopter, akkor lehet, hogy kialakul egy értelmes szakmai beszélgetés. Ha neked van tapasztalatod vele, vagy jobban utána olvastál, akkor akár meg is oszthatnád ezt a tudást velünk. Már persze, ha méltónak találod méltatlan személyünket bölcsességed fényének kiterjesztésére.
Blog | @hron84
via @snq-
Sajnálom, ennyi telik tőlem.
Ha megnézed, rengeteg helyen próbáltam, több módon is megmagyarázni, illetve a félreértéseket tisztázni. Egyedül bzt személyeskedésére sértődtem meg, mivel az pont, hogy "nem professzionális" és nem "alakul ki egy értelmes szakmai beszélgetés".
Éppen ezen igyekeztem ebben a topikban, nem sok sikerrel.
Az ilyen megjegyzések sem igazán viszik előre a szakmaiságot, már ne is haragudj!
Igen, én sem értem. Egyfelől írja, hogy nem névvel ellátott definíciók vannak, de aztán a linkelt oldalon a forráskódban kapásból több helyen van definíció, pl. list, tempmain, stb..
Ez sem tiszta nekem sem, hogy hogy ne lenne fordítási idő. Az még Assembly-nél is van, ott is át kell fordítani az opkódokat gépi kódra, meg össze kell az egészet linkelni, nehogy már egy magas szintű funkcionális nyelvnek ne legyen. Nonszensz.
Bár nem kizárt, hogy csak én nem értem, hogy mi ez a hash-elés. A funkcionális programozás amúgy is meghaladja a tudásom, többször nekiduráltam magam (Haskell, Common Lisp), de mindig lepattanok róla. Az alapokat megtanultam, de képtelen vagyok általános problémákat tisztán funkcionálisan leprogramozni, mert ugyebár teljesen eltér a hagyományos imperatív, strukturális nyelvektől, nincsenek ciklusok, elágazások, nem adhatsz értéket változóknak, mindent függvényeken keresztül kell használni, meg rekurzióval trükközni. Nem bírok hozzászokni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
En nem jartam nagyon utana, szoval tevedhetek is, de az eddig leirtak alapjan a forditasi ido annyi, amig az egy fajl/csomag/whatever lefordul, ami egy relative rovid ido (~= azonnal), ellentetben azzal, amikor mondjuk le kell buildelni egy komplett Docker image-t, es azt feltolni valahova, ami siman lehet orakban is merheto, ha eleg nagy a kodbazis.
Ha elég nagy az unison fájl/csomag/whatever, annak is lesz fordítási ideje. Nem a hello.c docker image -be csomagolása és feltöltése a leggyakrabban megoldandó probléma általában.
Blog | @hron84
via @snq-
Igen, errol beszelek. Nalunk az egyik projektnel nagyon nagy a varakozasi ido egy-egy uj valtoztatas kiprobalasakor, mert serverless functionoktol Kubernetesen at minden fiszemfaszom van benne.
Ha az Unison tudna azt, amit a marketing anyag iger, akkor szerintem napi 1 orat meg tudnank sporolni per fo. Azert az nem gyenge. Fel tudnek belole venni +3 embert, vagy ki lehetne osztani a 12%-ot extra fixuemeleskent. Es el lehet utni azzal, hogy de a hello.c meg a Docker, de nem mindenki ilyenen dolgozik, oda ez nyilvan felesleges, ezt asszem nem is vitatja senki, aki kicsit is ertelmes.
Egy másik fórumon feljött a Darklang nyelv, hogy kb. ugyanaz lehet.
Sok a hasonlóság, de alapvetően egészen más. Ezt az összehasonlítást írja AI-ranka:
"hanem azonnal élesbe küldhetik a kódot"
Ahammmm.... nem kell félni, jóóóóóólesssssssssssszzzzzzzzzz!!!! :)
Itt az "elesbe kuldeni" szerintem csak egy szofordulat arra, hogy megirod a kodot, aztan egybol mehet ki "valahova", de ez lehet akar a sajat gepeden futo jatszos sandbox is, nem?
Igen, így van.
Ezt kicsit kifejtem, mert félreérthető. Egy hagyományos nyelvnél kb. ilyen a build folyamata:
Ezeket minden egyes esetben el kell végezni, ha csak a kódbázis (git) van meg, de nincs futtatható állomány és/vagy módosul valamelyik része. Utóbbi esetben sok build rendszer képes bizonyos dolgokat ilyenkor a korábbi buildből felhasználni, így gyorsabb lehet a folyamat.
Unison esetén, amikor a kódot írjuk és elmentjük a fájlt, máris megtörténik a fordítás, ez alapján történik a hibák jelzése (mint IDE-nél). Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető, akkor feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is. Tehát elegendő mindig egyetlen egy fájlban szerkesztenünk az épp fejlesztendő kódot.
Ebben az egy esetben futott a fordítás és a teszt az adott kódra. Többször már nem lesz rá szükség, amíg meg nem változik, de akkor az már új kód. Linkelni sem kell, mert, ha a függőség nincs a kódbázisban, és az adott forrásban sincs, akkor nem fog fordulni sem.
Tehát a kódbázis mindig egy összeépített, futó kódot tartalmaz. A fordítás és teszt futtatás csak egyszer történik meg, a kódbázisba feltöltéskor, többször sohasem.
Ui.:
A kódbázisba tetszőleges definíciót felrakhatunk, pl. akár egyesével a megírt függvényt, vagy típust, ...
Pl. megírunk egy típust, felrakjuk, kitöröljük a forrását, megírunk egy fv-t, felrakjuk, kitöröljük a forrását, ...
Én még így sem egészen értem, de mindegy. Mondjuk ez a Darklang sem világosabb, ezzel a backend rizsával. Ezek most tényleg az évszázad zsenialitásai, és csak én vagyok hozzá túl hülye, vagy oltári nagy kamuk. Mindegy, még nem írom le őket, próbálok nézni róluk anyagokat, hátha megértem, hogy mi hajtja.
Van egy olyan érzésem, hogy ezek a Rust-nál is szarabbak lesznek, mondtam én pár napja a Rust ekézős topikba, hogy vissza fogjuk még sírni azt.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nekem ebből a leírásból olyasmi jön le, mint ha eleve lefordított java class fájlokat tárolgatnánk gitben, amiket utána nem org.example.MyUserImpl67, hanem 0xCAFEBABE formában hivatkozhatnánk meg a későbbiekben (az implementáció részleteitől függően, tehát content-addressed módon). Aztán, hogy a class fájlban egy interface vagy egy metódus implementációja van (granularitás), az már kb. mindegy is. Ilyesmiről van szó?
Igen, ilyesmiről van szó.
Kösz a hasonlatot, így már kezd egy kicsit érthető lenni, de ha ez tényleg így van, az a világ baromsága kb.. Egy kis fordítási idő spórálásáért cserébe bevállalják ezt az óriási szívást. Elmebeteg ötletnek tűnik. Ez semmi mást nem fog eredményezni, csak átláthatatlan, katyvasz, karbantarthatatlan kódokat, amiket később sem mer majd senki bottal sem piszkálni, eleve az egész kód bizonyos hash-ű, konkrét tárolójú kódra fog dependelni, semmi mással nem lehet majd futtatni, ha kiszeded az eredeti környezetéből, vagy megpróbálnád átportolni. Gratulálni tudok annak, aki kitalálta.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez egész konkrétan NEM IGAZ. Naponta százszor build-elek annélkül, hogy pl. függőségeket telepítenék vagy kódbázist töltögetnék le (ezeket elég egyszer az elején, nem kell "minden egyes esetben", minden build előtt megtenni).
Mondom én, az a bajod, gőzöd sincs róla, mi a különbség a build és a CI között, mert babzsákfotelfejlesztő vagy és még csak CI által hívott build-et láttál, semmi mást.
Ha egy mondatot kiragadsz és azt sem érted meg, ráadásul a következő mondatot már el sem olvasod, akkor teljes tévképzeteid lesznek.
Kár fröcsögnöd, ha két mondatot egyben már nem tudsz értelmezni!
"Unison esetén, amikor a kódot írjuk és elmentjük a fájlt, máris megtörténik a fordítás, ez alapján történik a hibák jelzése (mint IDE-nél). Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető, akkor feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is. Tehát elegendő mindig egyetlen egy fájlban szerkesztenünk az épp fejlesztendő kódot."
> minden függőség elérhető
Tehát akkor ezt nem spóroljuk meg:
> feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is.
Valószínűleg ez nem fogja segíteni a fejlesztést. A git se azért checkoutol teljes repositorykat, mert ne tudnánk 1-1 fájlt letölteni és szerkeszteni (a buildot meg megoldja a build szerver) hanem azért is, mert általában a fejlesztés kontextusában történik. Azaz emberként kell látnom a kód többi részét, hogy én tudjam írni a saját kódomat, hiszen függvényeket hívok, változókat használok, stb... Amúgy ezt bármelyik nyelvvel meg tudnám tenni.
> Ebben az egy esetben futott a fordítás és a teszt az adott kódra.
Itt nagyon nagy kérdés, hogy a teszt alatt milyen tesztet értünk. Mert ugye van unit teszt, integration teszt, stb. A teszt külön function?
> Linkelni sem kell, mert, ha a függőség nincs a kódbázisban
Mivel a te scenariodban csak 1 fájlt töltesz le, így a "kódbázis" nem biztos, hogy rendelkezésre áll, tehát valamilyen szintű linkelés kell, legalább annyira, hogy megnézze a "kódbázisban", hogy minden fasza-e. És igen, lehet, hogy ez a fájl mentésekor lezajlik, de a fájl mentése nem atomi művelet, _van_ benne fordítás _és_ linkelés is.
A másik, hogy ha van fordítás-visszafordítás, akkor egy komplexebb függvény esetén ennek a költsége nagyobb is lehet, elképzelhető, hogy érdemesebb lenne a "szerkeszthető", "olvasható" kódot külön is elmenteni, nem csak a compile-olt (byte)kódot.
Blog | @hron84
via @snq-
Szerintem te ezt nem erted (de lehet, hogy en sem)
Nem az a nagy truvaj, hogy egy desktop appon, vagy egy generikus 41684641784. php webshopon kivaltsa a "build idot" ez a cucc. Szerintem ez olyan dolgokra lett kitalalva, ahol nem 1 db jol korulhatarolt git repo van, hanem mindenfele microservice meg akarmi ossze van boritva, es Jenga-zol, hogy ha itt meghuzod az egyik fadarabot, akkor osszedol-e az egesz torony.
Erre a use case-re baromi jo az a logika, amit ebben felfedezni velek. Hogy a Unison konkretan jo-e, arrol fogalmam sincs, de az elkepzeles mindenkeppen eloremutato.
Offtopik, de nagyon regen nem lattam olyan architekturat, ahol a teljes kodbazis ismerete/meglete szukseges lett volna egy-egy feladat megoldasahoz. Kit erdekel, hogy a Hold tuloldalan milyen valtozoneveket hasznalnak? Dolgoztam olyan projekten, ahol 700 fejleszto dolgozott, szerinted erdekelt engem, hogy melyik modul melyik microservice-eben milyen valtozonevek vannak? :)
Az Unison kb arról szól, hogy a saját felhőjükre befizetsz és ők meg az egész felhőbe való natív app fejlesztésre/üzemeltetésre/... (a saját platformjukhoz) adnak egy programozási nyelvet, ami jó sok döntést meghoz helyetted és mindent "lekezel" (helyetted). Ezt lehet tekinteni kb a Serverless/Fn/Lambda/hogyhívjákmég továbbfejlesztésének és úgy néz ki, hogy kellett hozzá még egy ötlet a dep-kezelésre.
De alacsony(abb) szintű dolgokkal nem kell foglalkozni, mert azt "intézi" a platform. ;D
A felhős üzletpolitikájuk nekem sem tetszik egyáltalán. Emiatt könnyen lehet, hogy számomra csak az érdekesség szintjén fog megmaradni.
Akkor neked lehet hogy valójában az Erlang+OTP/Elixir kell (ha ajánlhatok valamit). :D
Köszi!
Nézegetem a Gleam-et is, ha már Erlang, az is tetszik.
Illetve a Roc is ;-) Illetve a Zig is ;-)
Van sok nyelv születőben. Mindegyiknek van valami kis érdekessége.
Hát érdekesek ezek, de mindegyik elvesztett engem: :D
- A Gleam kb a Javascript szintaxisát viszi az Erlang runtime-ra. Az meg egy undorító sértés. Babzsákfejlesztők játéka - ahogy a tudjukki mondaná. ;)
- A Zig egy tool nyelvnek ok, csak azt hiszem, hogy más területen már vesztett a Rust és a Go-val szemben. Ergo időpazarlás. ;)
- A Roc a legérdekesebb koncepció számomra, csak nincs még kész sajnos.
ML szintaxist visz, ami elég távolról hasonlít csak a Javascriptre.
Elég nagy sértés lenne valóban, de szemben a Javascript dinamikus típusával, script és procedurális jellegével szemben ez egy erősen, statikusan típusolt, fordított és teljesen funkcionális nyelv. Nagyobb a hasonlóság a Pythonhoz, ha egy kicsit más jellegű sértés, vagy dicséret felé indulunk ;-)
Miért lenne tool nyelv? Általános nyelv, szinte mindenre teljesen jól használható (web, kernel, tool-ok, általános alkalmazások). Azért is érdekes, hogy már vesztett is a Rust és Go-val szemben, hiszen még ki se jött a stabil verziója. Még Primeagen, aki nagyon nagy Go rajongó, is azt mondja, hogy jelenleg a legérdekesebb nyelv és "super cool"! ;-)
BTW a ROC szintaxisa is szinte ugyanaz, mint a Gleam-é. ;-)
Az hogy a Zig kicsit máshogy szeretne egy jobb C lenni, nem imponál általános programozási nyelvként. Az hogy vesztett, azt jelenti, hogy szerintem végzetesen lekésett arról a vonatról (C pótló, rivális), amin a másik kettő már fent ül és nem fogja elérni. :) Ez persze csak egy megérzés jelenleg (mint ahogy az Unison esetén is), hisz nem vagyok időutazó és jövőbelátó se.
A Gleam-nél nem tudom mihez kell a kapcsos zárójel használata, de nem tetszik és ezért nem is tudom a Roc-hoz hasonlítani (pedig az ML family-t kedvelem). :)
Igazad van, emiatt tényleg közelebb áll a C típusú nyelvekhez, mint az ML-ekhez.
Igen, a használandó külső library-k megkeresését, letöltését, telepítését nem ússzuk meg, de nem is írtam ezt, az a rész feltételes:
Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető,
Tudod látni a kódot, nagyon jó keresője van, pl. még szignatúrára is tudsz keresni: azon függvényeket listázd, ami Person-t kap és Boolean-t ad vissza. Majd megnyithatom ezeket megnézhetem a kódját, akár át is írhatom.
Kizárólag a unit tesztet.
Biztosan rendelkezésre áll a kódbázis, mert ebben nagyon hasonlít a gitre, van a home könyvtáradban egy saját, oda tudod belepakolni a dolgokat, majd onnan tudod feltölteni egy központi kódbázisba. A nálad lévő kódbázisban is mindennek "faszának" kell lennie.
A fájl mentésekor csak fordítás történik, a kódbázisba tevéskor ellenőrzi, hogy minden függőség rendben van és nem törik-e valami. Ha törne, akkor előbb ki kell javítanod és csak a javítással együtt tudod betenni a kódbázisba. A kódbázisban nem lehet olyan, hogy valami törik.
Itt kb. csak annyi történik, mint IDE-kben az ellenőrzésekkor (igazából még szerintem annyi sem). Nincs számottevő ideje.
Van még kérdés :D
Fedora 40, Thinkpad x280
Tetszik. Architektként kifejezetten élvezem, amikor egy környezetbe egy olyan megoldást hoz be valaki, ami egy teljesen másik környezetben született és annyira más világ, hogy az asszociációt is magyarázni kell.
Ez kb a k8s és az application streaming ötleteinek lehozása forrás szintre.
Egy dolog viszont zavar. Ha minden igaz, akkor ehhez kell egy szent központi "kód" (valójában artefact) tár, ami szigorúan monoton nő. Mindenki ide rakja a cuccait és a futtatás is ettől függ az első indításkor, mert innen húzza be a még hiányzó darabokat. Ez a szent kódtár hogyan skálázható és hogyan nem lesz SPoF? Hasonló volt a docker hub, amíg bele nem pusztultak a storage árába és ennek következtében el nem kezdtek takarítani és az ingyenes hozzáféréseket durván korlátozni.
Igen. Ami érdekes, hogy nem is a program nyelv maga, ami nagy változást okoz, az szinte teljesen Haskell szerű, kivéve az effect kezelés, az egy kicsit újdonság; hanem egy pici szemléletváltás, ami alapjában borítja fel az eddigi gondolkodásunkat a szoftver készítés menetéről.
A legjobb analógia a git (kódbázis) tároló. Ha mindent egy kódbázisba teszel, akkor végtelen méretűre is nőhet, de teheted sokba is akár. Egy nagyot is ki lehet szolgálni egyébként, ahogy a github, gitlab is meg tudja oldani. Ha egy cég összes forrása és annak összes története elfér egy git tárolóban, akkor ebben is el fog férni szerintem. Ám, nem szükséges mindent egybe rakni.
De ha behúzok egy külső függőséget, az lejön az én tárolómba, vagy majd futásidőben kérődik le a gyártótól, azaz egy tőlem független kód tárolóból? Ez a rész elég elnagyolt volt a bevezető anyagban és inkább úgy tűnt, mintha az utóbbi lenne.
Először le kell húznod a függőséget magadhoz, utána tudsz rá hivatkozni csak. Az így lehívott függőség bekerül a tárolódba és akár át is írhatod, átnevezheted, több verzióját is berakhatod, ...
A tárolódba csak úgy kerülhet be bármi is, ha az összes függősége már benn van, vagy vele együtt bekerül.
És hogy fog a függőség frissülni? Ha az adott dependencia külső tárolóban van, honnan fogja az én tárolóm tudni, hogy van új fejlesztés?
Blog | @hron84
via @snq-
Magatol (remelem) sehonnan, hanem amikor en, mint fejleszto ugy dontok, hogy X fuggoseg Y verziojat lecserelem, akkor majd megmondom neki.
Én nem hiszek azokban a "nyelvekben" ahol a nyelvvel együtt egy ökoszisztémát - nopláne terméket - le akarnak tolni a torkodon.
Így hiányzik mögüle az "akadémiai háttér", a valódi elvi újdonság.
Nem hiszem hogy valaha is fog jönni az iparból ilyesmi, az iparnak nem dolga az alapkutatás. A világon néhány cég van ami csinál ilyet (pl IBM) ők lehetnek kivételek.
Néhány dolga nekem is tetszik, szerintem kubernetesék, java-ék le fognak nyúlni belőle ötleteket de önmagában ez a sztori nem áll meg.
Az igazi nagy problémát - mikor szabadulunk meg végre az RDBMS-ektől? - ez se oldja meg.
Stateless "izékkel" a hülye is tud "hősködni". :)
Gábriel Ákos
Ennél a nyelvnél nem akarják az egész ökoszisztémát lenyomni a torkodon. Itt egyedül az az újdonság, hogy git helyett ucm van. Az ucm (Unison Codebase Manager) gyakorlatilag a git, a fordító, az értelmező és a dokumentáció kezelő egyben.
Ez a része nyílt forrású (MIT), bárki szabadon átírhatja, továbbviheti.
Van egy Unison Cloud nevű termékük, ami kb. egy Kubernates szintű dolog, az zárt forrású és fizetős. Ez utóbbi elvileg az RDBMS-ektől is megszabadíthat, mivel elosztott adattárolást is lehetővé tesz. Kis teljesítménnyel tudod használni ingyen ezt felhős szolgáltatással. Részletesebben nem ismerem ezt a részt.
Ui.: Itt nem "stateless izékkel" kell "hősködni". Minden lehet teljesen stateful.
kontra
Na tessék, még egy újabb önellentmondás.
Jobban belegondolva ez a működés teljesen életképtelen.
Legyen például egy egyszerű grafikus alkalmazás, amivel adatokat rögzítenek. A megrendelő azt kéri, adjunk hozzá egy új mezőt. Ekkor módosítani kell:
- a megjelenítést tartalmazó fájlt (pl. Windows-on .res, Mac-en .nib)
- a kontrollert tartalmazó fájlt, hogy az új adatot átadja
- a modellt tartalmazó fájlt, hogy az új adatot fogadja
- az adatsémát kezelő fájlt, hogy tárolja és betöltse az új adatot (mégha memdump is, kezelni kell a korábban lementett, új mezőt nélkülöző adatfájlok betöltését, vagy sikeres teszthez minimum konvertálni kell a korábbi tesztfájlokat)
Egy rakat fájlt kell módosítani ahhoz, hogy a program újra konzisztens állapotba kerüljön és egyáltalán meg lehessen kísérelni a fordítást és a tesztelést (persze belehányhatod az összes komponenst egyetlen egy fájlba...).
Elképzelni sem tudok rosszabb dolgot annál, mintsem hogy azzal pazaroljuk egy programozó drága idejét, hogy minden fájlmentés után várakoznia kell a fordításra és a tesztelésre, még akkor is, ha eleve tudja, hogy garantáltan nem fog menni, mert még nem vitte végig a teljes változtatást.
Nem érted miként működik, így az egész eszmefuttatásod téves.
Ugyan komplett üzleti feature szempontjából igazad lenne, de ha minden elem funkcionális, akkor belülről indulva egy komponens változtatása nem tör működést. Mivel még senki nem hivatkozik rá, mehet élesbe. A sorozat utolsó eleme a felület, így a felhasználó már egy működő láncot kap. Na az viszont érdekes szívásnak tűnik, hogy ez nem is tud másképp működni, tehát ha épp nagyon ráér a frontendes, akkor sem nyúlhat a feladathoz, amíg a többi rész el nem készült, mert még a repo-ba sem tudja feltölteni. Ennek feloldása lehetne, hogy üres mock definíciók készülnek minden komponenshez, ekkor viszont ugye amikor cseréled a mock-ot, változik a hash, az egész lánc összes eleméből új verziót kell kiadni, hogy már az új hash-ekkel legyenek láncolva. Hát nem mondom, hogy az eddigi infók alapján kerek a világkép, de ez lehet betudható annak, hogy nagyon felszínes információk alapján akarjuk megszakérteni azt a részét, ami már jócskán túlmutat a hello world szintjén
Ezzel a részével tökéletesen egyetértek!
Amik kiigazításra szorulnak a fentiekből:
Azt még hozzátenném, hogy itt az ötlet és az abból adódó következmények a forradalmiak, nem a konkrét nyelv és a konkrét megvalósítás. Azért is nehéz még konkrét véleményt mondani, mivel erősen fejlesztés alatt van, még nem egy kikristályosodott rendszer.
> futtatható kell legyen
Valójában itt törik az elmélet. Ugyanis csak úgy tudsz meggyőződni arról, hogy futtatható valami, hogy megfuttatod. Lehet bármilyen okos compilered, hibakeresőd, stb, lehet a kódban olyan logikai hiba, ami a statikus/AST elemzés során nem jön ki, de a nap végén nullával osztunk. Viszont, nem tudod megfuttatni, ha a függőségként behúzott függvények hashei(?) még nem állnak rendelkezésre. Ez kicsit a CD-n szállított CD driver esetének tűnik.
Itt ugyanis nem az önálló fejlesztésről van szó, hanem egy ökoszisztéma elemeinek párhuzamos fejlesztéséről. Ez kicsit mást jelent, ugye van külön backendes és frontendes fejlesztő, a backendes dolgozik az üzleti logikán a frontendes a megjelenítésen, és a jelenlegi nyelveknél ideiglenesen mindketten tudnak stubokkal/scaffoldokkal dolgozni, és majd egyszer a végtelenben találkoznak, viszont a fent vázolt ökoszisztéma esetén nem tudják összelinkelni/összekapcsolni függőség szinten a munkájukat, hogy egyben tudják tesztelni.
Blog | @hron84
via @snq-
A futtatható nem azt jelenti, hogy nem történik benne elszállás a futás során. Ha elindul, akkor futtatható.
Ha a függőséget behúzod, akkor az bekerül a kódbázisba, nem csak a hivatkozás hozzá, hanem a teljes kódja. Tehát a kódbázisban mindig ott van minden, külső dolgot nem kell behozni a futtatáshoz.
Szerintem ugyanúgy lehet fejleszteni, mint minden más alkalmazás esetén. Annyi itt a feltétel, hogy mindig csak futtatható kód kerülhet be a kódbázisba, de a legtöbb helyen ez elvárás, hogy git alá ne tegyünk nem futó (forduló) kódot. A bonyolítást az okozhatja, ha valami több verzióban van, akkor figyelni kell, hogy mi melyiket használja és ne legyen olyan, hogy valami a régi verzión ragad, mert nem figyeltünk oda.
Ezt egy mock implementációval éppen meg tudod kerülni, nem?
Gábriel Ákos
Nem. Egyrészről nem biztos, hogy a mock és a hívása egy fájlba kerül, másrészről ha csinálsz is mock-ot, fordulni ugyan fog, de a tesztek jó eséllyel eltörnek miatta, tehát nem fogod tudni pusholni a kódbázisba a mock-al sem, hacsak nem implementálsz bele elve egy minimális működést is, hogy átverd a teszteken. De ez felesleges plusz munka, ezenkívül bennfelejtheted a kódban a mock hívást, mert ilyenkor a tesztek le fognak futni a mock-ra is.
Szóval mock-al sem biztos, hogy egyetlen fájlt elég módosítani, és ha mégis egylépésben mockolható, akkor meg (más okból de) baj az is, ha nem fut le a teszt, meg az is, ha lefut. (Előbbinél nem tudsz menteni, utóbbi hosszú távon karbantarthatatlan.)
Ugye mivel a függvények hash-ükkel vannak azonosítva, ezért egyszerre érvényes lehet a régi, a mockolt és a rendes új implementáció is egy és ugyanazon kódbázisban, ezért képtelenség kiszűrni, ha valahol elfelejtetted átírni az újra, mert mind fordulni fog (szintaktikailag nem lesz probléma, ellenben szemantikailag igen, ez azonban fordításkor nem bukik ki, csak max. jó esetben tesztelésnél, rosszabb esetben élesben).
Ember legyen a talpán aki egy ilyen kódbázist (hiba nélkül forduló régi, mockolt és új függvényekkel) képes karbantartani.
Nincsenek fájlok. Kódbázis van, olyan adatbázis, ahol az összes definíció szerepel, amiknek a kulcsa a szintaxis fájának hash-e.
Ha rossz a kiindulásod, akkor a levezetés sem lehet jó.
kontra
Továbbra is tele van a magyarázatod ellentmondásokkal.
De tegyük fel, hogy nincsenek fájlok, a kódbázisba minden egységesen bele van fosva csoportosítás nélkül. Ez így nálam kapásból kizáró ok. De legyen, viszont ekkor sem igaz az, hogy minden mentésnél fordítani kéne, továbbra is fennáll, hogy több helyen kell módosítani a forráskódot ahhoz, hogy egy adott funkcionalitást végigvigyél és újra (szemantikailag) konzisztens állapotba kerüljön.
Van scratch fájl, amiben készíted az aktuális feltöltendő forrást. Amikor az fordul, akkor feltöltheted kódbázisba, és jöhet a következő adag, üres scratch fájllal indulva. A kódbázisba betöltött nem fájlokban van.
Nincs minden belefosva, van mindennek neve, vannak névterek.
Így van, ahogy ez minden más programnyelvnél is így van. Semelyiknél nem jó megoldás feltölteni olyan dolgot, ami nem fordul.
Itt annyi könnyebbség van, hogy kigyűjt neked mindent, ahol módosítanod kell.
Dehogynem. Ez csak egy példa volt, kismillió másik oka is lehet annak, hogy egy függvényhez új paramétert kell hozzáadni, vagy más okból módosítani kell a törzsén (ami azzal jár, hogy meváltozik a hash).
A gond akkor van, ha már létező függvényhez kell hozzányúlni, amire temérdek hivatkozás van. Ilyenkor bennmaradnak a régire a hivatkozások, és ezt semmiképp sem veszi észre neked az Unison (hisz a hash-el hivatkozik továbbra is a régire, hiába van ott az új, javított függvény is). Neked kell minden hivatkozást megkeresni és kézzel átírni (vagy vissza oda, hogy intelligens IDE kell hozzá).
De ez miert baj? Nem lehet invalidalni egy hash-t?
De miert ne hasznalnank normalis IDE-t?? Miert nem ez a default? Miert "vissza oda"? El sem mentunk onnan. 15 evvel ezelott is tudott olyat ~barmelyik IDE, hogy megkereste valamire az osszes referenciat, sot, refaktoralni is tudtak a normalisabbak.
Ehhez ráadásul pont nem is kell IDE, LSP-t tudó szövegszerkesztők pontosan jók, mert a refaktorálást és egyéb dolgokat az UCM (Unison Code Manager) intézi. Az ígéretek szerint még könnyebb is elvileg ezzel refaktorálni, mint egy hagyományos nyelv esetén.
Minek szopatod magad az Unison-nal, ha úgyis az IDE-vel oldod meg a problémákat? Használj akkor másik nyelvet, ami alapból sem szopás.
Mert azokat a problemakat, amire az Unison megoldast iger*, azokat nem mind lehet az IDE szintjen megvalositani.
* Hogy sikerul-e neki, azt tovabbra sem tudom, legyszi ne kezdjuk elolrol az ertetlenkedest.
Én csak azt látom, hogy azzal, hogy kiiktatod a szimbólumhivatkozást a forráskódból, és direkt AST hash-re cseréled, egy rakat új problémát veszel a nyakadba, de igazából nem árultátok el, mit is kéne, hogy megoldjon ez.
Továbbra sem kaptam sem tőled, sem enpassant-tól választ arra a teljesesen hétköznapi kérdésre, hogy mi van, ha módosítani kell egy már létező függvényt.
- a függvények hash-el vannak tárolva és hivatkozva
- ha módosul a függvény, akkor módosul nyilván a hash-e is, na de ilyenkor
. a) átíródik a hívás helyén is a hash? Ekkor törni fog a kód, nem tudsz menteni, hogy viszel végig egy több ponton történő módosítást ez esetben? (Hisz a mentés feltétele a sikeres fordítás)
. b) megmarad a régi hivatkozás a régi hash-el és új verzióként új hash-el elmentődik az új funkció? Ekkor mi és mikor garantálja, hogy majd egyszer minden hívás ki lesz cserélve?
Ha módosítod a függvényt, változik a hash-e, ekkor vagy cseréled a hivatkozásokat is vagy nem, több opció nincs. Mindkét eset további kérdéseket vet fel.
Egy szemléletes példával: olyan ez, mintha egy fájlrendszerben kiikatnád a tartalomfüggetlen fájlneveket (itt szimbólumhivatkozás), és tartalomfüggő hash-ekre cserélnéd (itt AST hash-ek). Hogy fog azonosítani ilyenkor egy program egy konfig fájlt mondjuk? Mi történik, ha átírod a konfigot, honnan fogja tudni a program, hogy milyen hash-el érhető el ezután? Vagy az továbbra is a régi konfigot használja a régi hash-el? Nem látom, hogy lenne haszna, de azt igen, hogy rengeteg problémával jár és számtalan kérdést felvet, ami fájlnevek (itt szimbólumhivatkozás) esetén egyáltalán nem is gond.
Olyan architekturalis nehezsegeket, amik pl. nekem a meloban napi szinten elojonnek. Ennek szolt a korabbi, "nem csak desktop fejlesztes van a vilagon" cimu kommentem.
Azt nem tudom, hogy megoldja-e, csak hogy azt allitja magarol, hogy meg tudna oldani, mert Unison-temaban csak erdeklodo vagyok, nem szakerto. <-- Legyszi ennek tudataban valszolj, mert enelkul ertelmetlen az egesz vergodes.
Most mar csak azt kellene elfogadni, hogy nem mindenki desktop appot fejleszt, a mi projektunkben pl. egesz hasznos lenne egy ilyen workflow, amit az Unison tud. Nyilvan nem fogjuk mar a nullarol ujrairni, de belegondolni sem merek, de belengondolni sem merek, mennyi emberora megy el azokkal a pocsolesekkel, amit ez (elvileg) kivaltana.
Most már csak azt kellene felfogni, hogy az csupán egy példa volt. Éppen úgy érvényes lehet mondjuk egy REST API kiszolgálóra is, vagy akár egy parancssoros toolra, stb.
Ezzel aztán most jól nem mondtál az égvilágon semmit sem.
Igen, es sok dologra meg nem ervenyes, akkor most mi legyen?
Szerintem aki akarta, ertette.
Cáfolathoz egyetlen ellenpéda is elég.
Mit? Nem hiszem, hogy bárki képes kiolvasni a fejedből, mire gondolhattál "pöcsölés" alatt, mert még csak példát sem hoztál rá.
Nem ertem, mit cafoltal?
Azt mindenki tudja, hogy nem érted, mert nulla gyakorlati tapasztalatod van.
Az ellenpélda (új mező hozzáadása egy adatrögzítő alkalmazáshoz) azt hivatott cáfolni, hogy jó dolog minden mentés után automatikusan fordítani és teszteket futtatni. Nyilván nem, aki programozott már valaha az életében, az tudja, hogy nagyon nem jó ötlet.
De lehetne végtelen számú másik ellenpélda is, ahol egy adott funkció implementálásához több helyen is bele kell nyúlni a forráskódba, hogy az (szemantikailag) konzisztens, fordítható és tesztelhető maradjon. Ha külön mockolósdit kell játszani minden egyes függvénymódosítás előtt, akkor ez az Unison nyelv - már elnézést a kifejezésért - egy kalap szar.
En arra tippelek, hogy te annyi idot sem toltottel el a doksi olvasasaval, mint en. Ez nagy szo, mert 2-3 percrol beszelnuk. Ennyi ido alatt siman kiderult, hogy nem, nem fut minden mentes* utan teszt.
Mentes, a kenyszeres kotozkodok kedveert: a ".u" kiterjesztesu scratch file valtoztatasait elmentjuk a lokalis diszkre.
Már megint egy csomó újabb ellentmondás... a kérdésemre válasz meg semmi, csak mellémagyarázás.
kontra
Na most akkor mégsem kell ellenőrzés és tesztelés a kódbázisba helyezéshez? Hogy tud lefordulni a lokális kódbázis, honnan tudja, hogy nem jött be újabb függőség, ha nincs ellenőrzés? Hogy fordulhat le lokálban, ha bejött egy újabb függőség, de azt nem is ellenőrzi, csak kódbázisba helyezéskor? Mi van, ha változott a függőség, és ez töri a lokális kódot?
Ez az egész nagyon zagyvaság, a magyarázataitok meg tele ellentmondással és értelmetlen hablatyolással.
Mert mar ne haragudj, de mi vagyok en, chatgpt? Eletemben egy sor Unison kodot nem irtam meg, csak tetszik a koncepcio, es ugy gondolom, bizonyos niche teruletek problemajat meg tudna oldani. Miert nem olvasod el a doksit?
Direkt neked irtam le, hogy mit jelent a "mentes" szo, olvasd el!
A tesztelés opcionális, ellenőrzés pedig automatikusan fut a kódbázisba helyezéskor és nem enged olyan állapotot, ami nem fordul (fut).
Mentéskor csak az a kis részlet fordul, amit a scratch fájlba írsz, azt ellenőrzi, de azt nem, hogy mi lenne akkor, ha bekerülne a kódbázisba. Ezt úgy kell elképzelni, mint IDE esetén ami mentéskor fut és hibákat, figyelmeztetéseket jelez az épp megírt kódban.
Új függőség nem tud csak úgy bejönni, azt be kell hozni. Kódbázisba helyezéskor azt ellenőrzi, hogy a korábbi definíció megváltozott-e, és ez okoz-e törést. Ha igen, akkor ezt ki kell javítani, addig nem lehet betenni a kódbázisba. Ehhez minden segítséget megad, kigyűjti az összes olyan definíciót, ahol használva van, és emiatt azt módosítani kell.
Ha érdekel, akkor olvasd el és nézd meg a megadott anyagokat. Ha nem érdekel, akkor meg nem értelek. (Csak gondolom, hogy ez csak trollkodás)
Lisp szagot érzek! Szerintem már ezt is feltalálták.
Ebből a videóból sokkal jobban megérthető az ötlet és a működése:
"Unison: a new distributed programming language" by Paul Chiusano