Swift je open source

V červnu bylo oznámeno, že Apple uvolní programovací jazyk Swift (Wikipedia) jako open source (zprávička). Stalo se tak dnes. Pro komunitu byly vytvořeny stránky Swift.org. Zdrojový kód je k dispozici na GitHubu. Podporován je také Linux.

3.12.2015 23:58 | Ladislav Hagara | Zajímavý software

Komentáře

[PH]

Hezká nová hračka :)

[Sid]

otazne je ci sa skor nerozhodnut pre rust vdaka urcitej spriaznenosti

[Bystroushaak]

Taky by mě zajímalo, proč by se někdo rozhodoval pro swift. Ten má jedinou výhodu v tom, že ho podporuje apple, a tudíž běží nativně na iZařízeních. Jinak imho nemá oproti ostatním co nabídnout, je to imho jen průměrný imperativní jazyk, kterých se všude povalují desítky.

[Zopper]

Roli může hrát i ekosystém a dostupná IDE. Viděl jsem nějaké zajímavé možnosti Xcode, které ale fungují jen v podporovaných jazycích. Otázka samozřejmě je, jestli se to vyplatí v praxi.

[PH]

Swift je OO a funkcionální, míchá to podobně jako Haskell, jenže v Haskellu se nedá tak prasit. Z hlediska návrhu (syntax, konstrukce, styl kódu) jde o jazyk nadprůměrný, některé konstrukce v jiných silně typovaných jazycích nejdou napsat. Navíc překládá hodně rychle (podobně jako Go). Jen ta standardní knihovna je děsný guláš. Chce to v tom pár tisíc řádek kódu napsat, než člověk vůbec pochopí styl a filosofii.

[Radek Miček]

Z hlediska návrhu (syntax, konstrukce, styl kódu) jde o jazyk nadprůměrný

Přijde mi jako osekaný C# (což není úplně špatně) s protokoly a vestavěným optional.

C# má však lepší GC (Swift používá počítání referencí, což je problematické – cykly + špatný výkon v paralelním prostředí), lepší knihovny a momentálně i otevřenější vývoj.

některé konstrukce v jiných silně typovaných jazycích nejdou napsat

To platí i naopak.

[PH]

Počítání referencí je lepší z hlediska výkonu.

[Radek Miček]

Počítání referencí je lepší z hlediska výkonu.

Pro většinu aplikací to neplatí.

U aplikací, které používají málo paměti (max. pár GB) a většina hodnot tam má krátkou životnost (tj. krátce po alokaci již nejsou potřeba), je klasické počítání referencí o dost pomalejší, než generační GC s mark and sweep. Proto např. implementace Javy, C# a řady funkcionálních jazyků nepoužívají klasické počítání referencí.

Další problémy s klasickým počítání referencí jsou paměť navíc (cache zaplníte počítadly a klesne výkon programu), problémy se synchronizací v paralelním prostředí (opět může značně snížit výkon), problémy s lavinovitým uvolňováním paměti (dlouhé pauzy programu).

[kyknos]

nevim o tom zhola nic, ale dlouhé pauzy programu jsou mi temer synonymem s javou

[Radek Miček]

Mám na mysli situaci, kdy uvolníte poslední referenci na rozsáhlou stromovou strukturu – v ten okamžik se začnou uvolňovat její jednotlivé uzly, a když jich je mnoho, tak vlákno programu, kde došlo k uvolnění, na chvíli zatuhne. Samozřejmě, uvolňování jde rozdělit na menší celky (například dát do fronty a tu průběžně vyprazdňovat), nicméně tím ztrácíte hlavní výhody počítání referencí – opět nevíte, kdy přesně budou hodnoty uvolněny.

Více viz How do reference counting and garbage collection compare? – odpověď Jona Harropa.

[PH]

U krátkodobých objektů se ale nepočítá nic, překladač změnu čítače vyhodí, když není potřeba (viz optimalizace v clangu). Čítač se aktualizuje jen u objektů, jež opustí scope.

[Radek Miček]

Já vím, i tak je to příliš pomalé.

[PH]

Když se nemění čítač referencí, tak nic rychlejšího existovat nemůže. Ledaže by se objekt alokoval ma zásobníku, což se ostatně v lepších překladačích děje.

[Radek Miček]

Když se nemění čítač referencí, tak nic rychlejšího existovat nemůže.

Problém je i s těmi počítadly, jenž zabírají místo v cache.

Navíc, čítač referencí se v praxi mění. I když úplně ignorujete všechny lokální proměnné (nevím, zda tohle dělá clang), tak stejně zaplatíte za ZCT (zero count table) nebo něco podobného – viz třeba Garbage collection internals for Flash Player and Adobe AIR, část Deferred reference counting.

V určitých situacích může mít dobrý výkon Ulterior Reference Counting: Fast Garbage Collection without a Long Wait, jenže to už je hodně daleko od klasického počítání referencí a od Swiftu.

[PH]

Nevím, jak to je ve Swiftu, ale předpokládám, že stejně jako v ObjC. Každý jazyk mající vtable nebo něco na ten způsob musí do instancí objektů cpát ISA, což je pole zpravidla deklarované v kořenové třídě. ObjC cpe čítač referencí do něj, takže se žádná paměť navíc (oproti Javě či C#) nezabírá. ObjC pochopitelně (na rozdíl od Swiftu) nemůže dávat instance tříd na zásobník, ale překladač provádí statickou analýzu a operace pro akutalizace čítače z výsledného kódu vyhodí (protože jsou "balancing", je to něco jako krácení zlomků napříč metodami). To jen tak trochu teorie pro informaci, důležitá je nakonec stejně praxe a benchmarky ukazují, že tento způsob (ARC, neboli automatické RC) je výkonnější než "tracing" GC. U manuálního RC by ty informace ze statické analýzy měly jít použít také, ale v tomto případě žádné zevrubné benchmarky nemám, takže nemohu v praxi porovnat.

[Radek Miček]

ObjC cpe čítač referencí do něj, takže se žádná paměť navíc

Je to paměť navíc na každou instanci (tracing GC potřebuje pár bitů, u počítání referencí to je pár bajtů).

protože jsou "balancing"

To samo o sobě nestačí, pokud by počet referencí mohl klesnout na 0 (pak právě potřebujete ZCT).

benchmarky ukazují, že tento způsob (ARC, neboli automatické RC) je výkonnější než "tracing" GC.

Pokud znáte nějaké studie, tak se na ně rád podívám. To, co navrhujete, studovali například Deutsch a Bobrow v roce 1976 a později Cann a Oldehoeft v roce 1988 (Reference count and copy elimination for parallel applicative computing). Jsou to jednoduché techniky, které bohužel nestačí na tracing collector (kdyby stačilo něco tak jednoduchého, všichni by to dnes používali).

[PH]

Implementaci RC ve Flashi neznám, je možné, že tam je pomalá. Nicméně pokud se bavíme o ObjC (a potažmo Swiftu), tam žádná Zero Count Table není a vyvážené RC optimalizátor prostě vyhodí bez jakýchkoliv dalších komplikací. Nic jiného v tom není. Kdyby to takto nešlo, Apple by to těžko implementoval. Zkusím najít ten odkaz, kde to je popsané, nemá smysl, abych to tu podrobněji popisoval, v tom "oficiálním" dokumentu je to vysvětlené podrobněji a lépe, než kdybych se to snažil vysvětlit já zde.

[Radek Miček]

To pak nejspíše znamená, že ObjC manipuluje s počítadly více než Flash. Čekal bych tedy, že to bude pomalejší implementace počítání referencí.

[Radek Miček]

Našel jsem si novější článek Taking Off the Gloves with Reference Counting Immix a píší tam:

Many of the optimizations we describe here require the same runtime support as a tracing collector, undermining a principal advantage of a simple implementation. The reference counting implementations in widely used languages such as PHP and Objective-C are naive. Because they lack these optimizations, they are inefficient. Shahriyar et al.’s collector implements all these optimizations and is our RC baseline.

[little.owl]

Nemusi a casto neni, zejmena u vicejadrovych systemu.

[PH]

To není pravda, většina procesorů má rychlé instrukce pro atomický inkrement/dekrement.

[Boris Dušek]

cykly

weak

[Radek Miček]

To přidělává práci programátorům a je to náchylné k chybám.

Navíc to může být docela komplikované: Jednak cykly musíte objevit (tj. musíte vědět, jak systém funguje) a poté je musíte nějak rozbít. Pokud se graf referencí dynamicky mění, může se stát, že budete muset některé slabé reference měnit na silné.

[kralyk z abclinuxu]

+1, ta podpora na iOS + ten ekosystém okolo jsou imho jedinou zajímavou "vlastností" tohohle jazyka. Rust oproti tomu je zajímavý jako jazyk, ale zas mu docela chybí ten ekosystém, alespoň zatím.

BTW. co říkáte na Scalu? Teď nedávno jsem se k tomu dostal, protože se začíná používat v jednom projektu, a musím říct, že mě to příjemně překvapilo. Přijde mi to jako super náhrada za Javu. Člověk může psát javovské aplikace (i pro Android), ale přitom se nemusí babrat s Javou a může použít něco, co má expresivitu o řád jinde.

[Radek Miček]

BTW. co říkáte na Scalu?

Stále je tam řada drobných problémů – například kolekce (problémy s časovou složitostí některých operací) nebo IDE (nepodporují složitější konstrukce) nebo rychlost kompilátoru. Hodně mi tam také chybí TCO, což je ale spíše problém JVM.

[Bystroushaak]

BTW. co říkáte na Scalu?

Kdybych byl nucený používat Javu jako platformu, tak bych asi šel do clojure.

[kyknos]

+1

[kralyk z abclinuxu]

Hmm, nikdy jsem nepochopil, proč je Lisp pro některé lidi tak atraktivní...

[Bystroushaak]

A pochopil jsi lisp? Já mám v plánu na téma lispu napsat článek, ale to bude ještě pár let trvat.

[kralyk z abclinuxu]

Nevím úplně, co by tam mělo být zvláštního k pochopení oproti jiným jazykům...

[Bystroushaak]

...

[Radek Miček]

+1 Také bych to rád věděl.

[Bystroushaak]

Co třeba lispovská makra? Quote, quasiquote, unquote? Rekurzivní algoritmy? Já teda nevím jak ostatní, ale když jsem pochopil meta-circular evaluator, tak se dá říct, že to změnilo pohled, jakým se dívám na programovací jazyky.

[Radek Miček]

Co třeba lispovská makra? Quote, quasiquote, unquote? Rekurzivní algoritmy?

Makra dnes máte i v jiných jazycích a řekl bych, že i pokročilejší. Například Scala má implicitní makra – nemusí je volat programátor ručně, ale volá je kompilátor automaticky, když potřebuje vygenerovat nějaký kód, jenž mu programátor nedodal (například kód pro serializaci typu – když ho nenapíšete vy ručně, může kompilátor automaticky vygenerovat nějaký default).

meta-circular evaluator

AFAIK tohle už tak rozšířené není a v mainstreamových jazycích ani tak jednoduché (bez dalších knihoven).

[Bystroushaak]

Makra dnes máte i v jiných jazycích a řekl bych, že i pokročilejší.

Nevím jak ve Scale, ale zatím jsem nikde jinde neviděl nic, co by se alespoň blížilo komfortu procházení po AST stromu. Možná kromě Selfu, kde je možné procházet strom objektů hodně podobným způsobem.

[Radek Miček]

Nevím jak ve Scale, ale zatím jsem nikde jinde neviděl nic, co by se alespoň blížilo komfortu procházení po AST stromu.

Ve Scale můžete použít pattern matching anebo Traverser.

[Bystroushaak]

Tak ano, to jde skoro všude, ale je to stejně komfortní jako v lispu? Tzn dá se to používat bez toho, aniž bych měl pocit, že dělám něco extra speciálního? Já jsem párkrát sestavoval/procházel AST strom i v pythonu, ale moc nadšený jsem z toho teda nebyl.

[Radek Miček]

Pattern matching jde provádět i do hloubky – čekal bych tedy, že procházení bude o něco pohodlnější než v Pythonu.

Tak ano, to jde skoro všude, ale je to stejně komfortní jako v lispu?

Na druhé straně ne všechny lispy mají pattern matching – některé transformace AST tam budou asi méně přehledné.

[little.owl]

Lisp je homoikonicitni, kdy data a kod jsou to same a kdy vlastni kod jsou Lisp objekty a IMHO Scala homoikonicitni neni. Makra Lispu dokazi diky tomu zmenit syntaxi Lispu a tudiz ho pomoci maker lze doslova transformovat na jiny jazyk.

[Radek Miček]

Makra Lispu dokazi diky tomu zmenit syntaxi Lispu a tudiz ho pomoci maker lze doslova transformovat na jiny jazyk.

Na to ale potřebujete tzv. reader makra, ne?

[little.owl]

Vetsinou ano, ale nekdy ne, makro/syntaxe ma v Lispu ponekud sirsi vyznam. S-expressions a prefix notaci nelze uniknout. Viz zde ci Racket (spise dialect Scheme) zde.

[Radek Miček]

Chápu, měl jste na mysli změny syntaxe v rámci S-výrazů.

[deda.jabko]

Vicemene nepotrebujes. Predrecenik asi myslel to, ze diky homoikonicite a makrum neni tezke do jazyka doplnit libovolny konstrukt, ktery potrebujes. A proto se v tom da pracovat prave lip nez v beznych jazycich(TM). Da se totiz pracovat tak, ze si nejdriv napises "rozsireni jazyka" pro konkretni reseny problem (domenu) a pomoci nich resis skutecny problem. Jinymi slovy, jazyk ti dava moznost velice rychle, jednoduse a primocare zavest vlastni DSL a pracovat tak s danym problemem primo, misto toho, abys resil dany problem v jazyce, ktery pro to neni primo staveny a nuti te tak resit spoustu veci okolo.

[little.owl]

Predrecenik asi myslel to, ze diky homoikonicite a makrum neni tezke do jazyka doplnit libovolny konstrukt, ktery potrebujes.

Ano, takhle se i Lisp vyvijel. Plno "standardnich funkci" je fakticky makro, ktere muze byt v programu dynamicky rekompilovano a definovat vlastni syntaxi.

Da se totiz pracovat tak, ze si nejdriv napises "rozsireni jazyka" pro konkretni reseny problem (domenu) a pomoci nich resis skutecny problem.

Ta rozsireni jazyka mohou byt i velmi drasticka, kdy se fakticky jedna o jiny jazyk. Neznam jiny rozsireny a standardizovany jazyk, ktery by toto umoznoval.

[Bystroushaak]

Neznam jiny rozsireny a standardizovany jazyk, ktery by toto umoznoval.

Rebol. Ten tedy není zrovna moc rozšířený, ale standardizovaný ano. V srdci je to v podstatě lisp, s trochu jinou syntaxí.

[little.owl]

Standardizovany ano? Takze to ma ISO/ANSI/ECMA standard?

[Bystroushaak]

Má to jazykový standard vytvořený tvůrcem/tvůrci jazyka. Stejně jako třeba python.

[little.owl]

Tedy nic.

[Bystroushaak]

Proč je podle tebe ISO standard víc, než standard daný tvůrcema jazyka?

[little.owl]

V principu ano.

[Bystroushaak]

Neptal jsem se jestli ano, to je zřejmé. Ptal jsem se proč.

[little.owl]

Opravdu vam neni jasne z jakych duvodu se provadi pomerne nakladana standardizace programovacich jazyku?

[pavlix]

Když se dívám na ty výsledky, tak mi to kolikrát jasné není.

[little.owl]

A bez standardu by to bylo lepsi? Tohle je casto argumentace lidi, kteri se nedostali mimo gcc/clang/msvc, Linux ci Windows, v projektech kde se podle EULA neruci vubec za nic. Po zkusenostech treba s heterogennimi platformami od TI, kde mohou byt ctyri ruzne toolchainy pro ruzna jadra a OS, operujici nad sdilenou pameti, s generovanym ci starsim kodem, ci ruznymi embedded zmetky, jsem rad za C/C++ standard, ostatne uz i jen kvuli SIL certifikaci kompilatoru.

[Bystroushaak]

Ne, není.

[Radek Miček]

Ta rozsireni jazyka mohou byt i velmi drasticka, kdy se fakticky jedna o jiny jazyk. Neznam jiny rozsireny a standardizovany jazyk, ktery by toto umoznoval.

Jde to i v Prologu.

[kralyk z abclinuxu]

Což je další takový velice praktický jazyk

[Radek Miček]

Shodou okolností je metainterpretr i tradiční úlohou v Prologu (díky tomu jsem si na Prolog vzpomněl):

solve(true).
solve((A,B)):-
   solve(A),solve(B).
solve(A):-
   clause(A,B),solve(B).

Zdroj: Guide to Prolog Programming, Meta-Interpreters.

[kralyk z abclinuxu]

Já se s meta-interpreterem setkal u Befunge. Teda kromě Prologu, na ten jsme měli předmět ve škole. Osvícení jsem nedošel ani u jednoho...

[kralyk z abclinuxu]

Jinymi slovy, jazyk ti dava moznost velice rychle, jednoduse a primocare zavest vlastni DSL a pracovat tak s danym problemem primo, misto toho, abys resil dany problem v jazyce, ktery pro to neni primo staveny a nuti te tak resit spoustu veci okolo.

Zavádět si DSL per-problém má imho marginální výhody, general purpose jazyky jsou většinou dostatečně dobré na to, aby se v nich naprostá většina věcí dala rozumně vyjádřit. Naproti tomu to ale má značné nevýhody - je nutné se pokaždé, když člověk přijde k novému týmu / projektu učit nové DSL.

Čili tuhle vlastnost bych zhodnotil celkem jednoznačně jako nevýhodu.

[Bystroushaak]

DSL v lispu není to samé, jako DSL v jiných jazycích. Pořád máš na dně S-expressions.

[kralyk z abclinuxu]

Nepřijde mi, že by to hrálo nějakou zvláštní roli, nejlepší pro zvládnutí DSL (nebo jazyka) je stejně hlavně dokumentace. A vůbec nejlepší je, když se s žádným DSL nemusím zatěžovat

[deda.jabko]

Zavádět si DSL per-problém má imho marginální výhody, general purpose jazyky

Ty ale nevytvaris ciste DSL, ale rozsirujes obecny jazyk o DSL, takze mas obecny jazyk + DSL.

general purpose jazyky jsou většinou dostatečně dobré na to, aby se v nich naprostá většina věcí dala rozumně vyjádřit.

To same jde rict i o strojovem kodu, assembleru, ...

Naproti tomu to ale má značné nevýhody - je nutné se pokaždé, když člověk přijde k novému týmu / projektu učit nové DSL

Toto je naprosto nevalidni argument. V beznych jazycich se musis ucit zase funkce, procedury, metody, ne? Tady navic pracujes jen s dalsi formou abstrakce.blockquote

[kralyk z abclinuxu]

To same jde rict i o strojovem kodu, assembleru, ...

Imho nejde.

Toto je naprosto nevalidni argument. V beznych jazycich se musis ucit zase funkce, procedury, metody, ne? Tady navic pracujes jen s dalsi formou abstrakce.

No jo, ale to stále přidělává práci, ne? I v jazycích, které mají makra (třeba makra v Rustu nebo Scale taky pracují s ASTem) je typicky snaha použití maker minimalizovat, používat je pouze pro specielní případy, právě protože zvyšují náklady na porozumění zdrojáku...

[deda.jabko]

Imho nejde.

Imho jde. Je to jen o uhlu pohledu na to jakou uroven abstrakce povazujes za dostatecnou, protoze makra nedelaji nic jineho nez pridavaji dalsi formu abstrakce.

Jinak pokud jsou bezne jazyky na vsechno dostacujici, proc se na parsovani pouzivaji generatory prekladacu a ne bezne objekty/metodu/funkce? Proc bylo nutne ohnout C#, aby se tam vesel LINQ? Proc v Jave jak na bezicim pasu vznikaji nastroje, ktere pomoci anotaci transformuji jeden kod na jiny? Proc vznikaji ruzne templatovaci enginy, neslo by to delat primo v tom samem jazyce?

No jo, ale to stále přidělává práci, ne?

Na to jsi prisel jak? Z pohledu citelnosti je pro me uplne jedno jestli je (and foo bar) uzivatelem definovane makro, ci primitivum jazyka.

v jazycích, které mají makra (třeba makra v Rustu nebo Scale taky pracují s ASTem) je typicky snaha použití maker minimalizovat, používat je pouze pro specielní případy, právě protože zvyšují náklady na porozumění zdrojáku...

Divas se na Lisp prizmatem druhych jazyku, takze ti vyjde pokriveny vysledek. Tim, ze vsechno je S-vyraz a pouziva se prefixova notace, se ty rozdily hezky stiraji.

[kralyk z abclinuxu]

Jinak pokud jsou bezne jazyky na vsechno dostacujici, proc se na parsovani pouzivaji generatory prekladacu a ne bezne objekty/metodu/funkce?

Nenapsal jsem, že "běžné jazyky" (běžný prací prášek? ) jsou na všechno dostačující, celkem zjevně nejsou. Jsou ale dostačující většinou. Na zbytek mají různé ohýbáky, které se asi Lispistům ideově nelíbí, nicméně v praxi jsou dostačující.

Na to jsi prisel jak? Z pohledu citelnosti je pro me uplne jedno jestli je (and foo bar) uzivatelem definovane makro, ci primitivum jazyka.

Pokud to je uživatelem definované makro, můžu mít pochybnosti, co to dělá. (A to není jen věc Lispu, stejným způsobem je dobré nepřehánět třeba operator overloading v C++ (viz co navařili v U++)).

Jinak (and foo bar) je velmi jednoduchý příklad, já měl na mysli spíš třeba něco jako (defclass foobar ...). Pokud budu vědět, že se pohybuju v CL, budu předpokládat, že se jedná o CLOS (což ale taky nemusí být pravda, že). Pokud budu třeba v Scheme, už moc nevím, co to vlastně dělá, dokud si nepřečtu dokumentaci nebo nerozluštím místní zdroják defclass.

[Bystroushaak]

Pokud to je uživatelem definované makro, můžu mít pochybnosti, co to dělá. (A to není jen věc Lispu, stejným způsobem je dobré nepřehánět třeba operator overloading v C++ (viz co navařili v U++)).

To nějak nechápu. Proč bys ty pochybnosti neměl u funkcí a měl je zrovna u maker?

[kralyk z abclinuxu]

Pro funkce to platí samozřejmě taky - viz moje poznámka o operator overloading v C++, to jsou také funkce - nicméně makra mají mnohem větší svobodu než funkce, takže mohou více 'překvapit'. Krom toho, jedná se mi spíš o ty komplexnější případy, viz. to s tou třídou.

[Bystroushaak]

Makra v lispu jsou funkce, které nevyhodnocují argumenty před přijetím. Je tam možnost překvapení (nehygienická makra), ale na tu je upozorněn každý programátor hned z úvodu.

[deda.jabko]

Muzu mit v programu funkci sin(x), ktera mi bude pro x vracet sinus, ale pokud budu mit aplikaci pro biblicky krouzek, tak to mi muze vracet seznam hrichu. V cem je problem?

[kralyk z abclinuxu]

Muzu mit v programu funkci sin(x), ktera mi bude pro x vracet sinus, ale pokud budu mit aplikaci pro biblicky krouzek, tak to mi muze vracet seznam hrichu. V cem je problem?

V čem vidím problém jsem popsal na konci příspěvku.

[little.owl]

I v jazycích, které mají makra (třeba makra v Rustu nebo Scale taky pracují s ASTem) je typicky snaha použití maker minimalizovat

U Lispu jsou makra soucasti jazyka.

, používat je pouze pro specielní případy, právě protože zvyšují náklady na porozumění zdrojáku...

Muze a nemusi, skutecne zavisi na tom jak je pouzijete.

[Radek Miček]

U Lispu jsou makra soucasti jazyka.

Ve Scale jsou také součástí jazyka.

[little.owl]

Rekneme skutecnou first-class soucasti jazyka stojici na velmi jednoduche konzistentni syntaxi, kdy i zakladni veci jako assignment jsou implementovany jako makro, takze je lze redefinovat a kdy transformace kodu je normalni soucast kompilace.

Zkuste si precist toto vlakno, ktery ilustruje nektere aspekty Lispu:

In Lisp, source filters never break.

Never.

In Lisp, the **assignment operator** is a macro, implemented by a
source filter.  Every time you perform an assignment, you are invoking
a macro that analyzes the source code at compile time and rewrites it
to something else.  If source filters were even 0.01% unreliable in
Lisp, one assignment in 10,000 would compile wrong, and none of your
programs would ever work properly.  But they do work properly.  That
is how reliable source filters are in Lisp.  How does Lisp attain this
reliability?

In most programming languages, syntax is complex.  Macros have to take
apart program syntax, analyze it, and reassemble it.  They do not have
access to the program's parser, so they have to depend on heuristics
and best-guesses.  Sometimes their cut-rate analysis is wrong, and
then they break.

But Lisp is different.  Lisp macros *do* have access to the parser,
and it is a really simple parser.  A Lisp macro is not handed a
string, but a preparsed piece of source code in the form of a list,
because the source of a Lisp program is not a string; it is a list.
And Lisp programs are really good at taking apart lists and putting
them back together.  They do this reliably, every day.

Here is an extended example.  Lisp has a macro, called "setf", that
performs assignment.  The simplest form of setf is

        (setf x whatever)

which sets the value of the symbol "x" to the value of the expression
"whatever".

Lisp also has lists; you can use the "car" and "cdr" functions to get
the first element of a list or the rest of the list, respectively.
Now what if you want to replace the first element of a list with a new
value?  There is a standard function for doing that, and incredibly,
its name is even worse than "car".  It is "rplaca".  But you do not
have to remember "rplaca", because you can write

        (setf (car somelist) whatever)

to set the car of somelist.

What is really happening here is that "setf" is a macro.  At compile
time, it examines its arguments, and it sees that the first one has
the form (car SOMETHING).  It says to itself "Oh, the programmer is
trying to set the car of somthing.  The function to use for that is
'rplaca'."  And it quietly rewrites the code in place to:

        (rplaca somelist whatever)

There is also a function "nth" that gets the n'th element of a list;
if you want to modify the 3rd element of some list, you can use:

        (setf (nth 2 somelist) whatever)

The setf macro sees this and says to itself, "Oh, you are trying to
set the third element of something.  I know how to do that.  I will
use the special nonstandard builtin function 'setnth'" And it quietly
rewrites your "setf" form to:

        (setnth 2 somelist whatever)

A different Lisp system might rewrite it differently.

[Radek Miček]

zakladni veci jako assignment jsou implementovany jako makro

Tohle můžete udělat i preprocesory v OCamlu nebo makry ve Scale. Koneckonců plnohodnotný jazyk lze vybudovat i nad lambda kalkulem (tj. stačí proměnné, volání funkc = aplikace funkcí, a definice anonymních funkcí = lambda abstrakce).

[little.owl]

Jiste, ano, implementovat cokoliv mohu i v brainfuck, jenze to neni pointa.

preprocesory v OCamlu

A proto tu mame camlp4, camlp5 ci MetaOCaml, ktere stale vypadaji spise jako experimentalni pokusy. Je komicke, ze padesat let stara Lisp implementace makro subsystemu, ktera se vejde do 40 radku Lispu, se bere jako reference a stale to neni ono (Yaron Minsky, camlp5).

plnohodnotný jazyk lze vybudovat i nad lambda kalkulem

Tohle je puvodni publikace, kde John McCarthy v roce 1960 predstavil Lisp, a typed lamda calculus mel vliv na jeho design.

[Radek Miček]

Toto je naprosto nevalidni argument. V beznych jazycich se musis ucit zase funkce, procedury, metody, ne? Tady navic pracujes jen s dalsi formou abstrakce

S makry lze provádět dost věcí, což je právě ta jejich nevýhoda. Často (alespoň ve Scale) stačí pár maker, která pokryjí většinu potřeb uživatelů (například knihovna shapeless ve Scale). Je pak otázkou, zda jazyk vůbec má mít makra, nebo by bylo lepší přidat funkcionalitu těch pár maker přímo do jazyka.

[Radek Miček]

Makra Lispu dokazi diky tomu zmenit syntaxi Lispu a tudiz ho pomoci maker lze doslova transformovat na jiny jazyk.

Na to ale homoikonicita není nutná, ne? Například v OCamlu šlo pomocí nástroje Camlp4 libovolně měnit gramatiku jazyka.

Nebo na první pohled "změny syntaxe" můžete dosáhnout v jazycích s mixfixovými operátory. Například if-then-else se tam zadeklaruje jako obyčejná funkce:

if_then_else_ : {A : Set} → Bool → A → A → A
if true then x else y = x
if false then x else y = y

[deda.jabko]

Obrazne receno pro jednotlive stromy asi nevidis les. Ano, podobnych vysledku lze dosahnout i jinymi technickymi prostredky, napr. temi mixfixovymi operatory, ale neni to totez.

Diky S-vyrazum se stiraji rozdily mezi tim, co je jazyk jako takovy, jeho rozsireni a dokonce data (velmi prakticka vec). Hlavni vyhoda je, ze ti makra davaji _intuitivni_ prostredek, jak si ohybat jazyk svym potrebam pri reseni konkretniho problemu. Viz muj komentar vyse.

[little.owl]

Koukaje na Camlp4, prijde mi to stale spise jako preprocesor.

Homoikonicita je vlastnost jazyka, nikoliv algoritmus ci implementacni zalezitost. V Lispu jsou kod i data stromy S-expressions a mohou byt explicitne [temer neomezene] meneny jako data, stejne tak [temer neomezene] spousteny jako kod, kdy Lisp kod je fakticky AST. Samotne jadro Lispu je velmi male, kdy Lisp v Lispu/Scheme muze mit cca 30 radek - meta-circular evaluator, nastin puvodni McCarthy implementace zde ci 90 radku v pythonu zde. Zbytek muze byt self modifikovatelny kod i kdyz v praxi je to omezeno na urovni standardni implementace z vykonostnich duvodu.

[Radek Miček]

Koukaje na Camlp4, prijde mi to stale spise jako preprocesor.

Ano, je to preprocesor, který v sobě obsahuje gramatiku (skoro) OCamlu. Dříve byl oficiální součástí systému OCaml, nedávno byl však nahrazen PPX. PPX už nedovoluje měnit gramatiku (IDE s tím měla problémy) – místo toho byl AST rozšířen o atributy a PPX může tyto atributy využívat.

[kralyk z abclinuxu]

Makra Lispu dokazi diky tomu zmenit syntaxi Lispu a tudiz ho pomoci maker lze doslova transformovat na jiny jazyk.

Ok. Otázka pro lispisty. Transformujme Lisp na Rust. Mějme následující kód:

use std::thread;

fn main() {
    let mut x = Box::new(3);   // Alokace resource x. V tomto případě prosté číslo, může to být cokoli...

    let t = thread::spawn(move || {
        *x += 1;   // Mutabilní přístup k resource x
        println!("spawned thread: {}", x);
    });

    println!("main thread: {}", x);

    t.join();
}

Kompilace selže na té řádce s tím druhým println s chybou use of moved value: `x`, protože x bylo přesunuto do jiného vlákna a je potřeba zabránit race condition (a vyřešit memory management, ale to je v tomto případě vedlejší, protože to v lispu řeší gc). Jak by se tohle udělalo v Lispu?

[kralyk z abclinuxu]

Fakt nikdo nic?

[Hans1024]

Otazka pro Rustare. Counter-Strike je napsany v C++. Jak byste ho napsali v Rustu?

Nikdo nic?

[kralyk z abclinuxu]

Stačilo by mi to principielně. Jinak CS v Rustu by byl principielně napsán v podstatě stejně jako v C++.

[little.owl]

Tak ownership je velmi hezka vec Rustu. Lisp je ted ve stejne situaci jako jako C++ pred C++11, to znamena puvodni standard se thready nepocital a bude to az v pristim updatu.

Ted si to kazdy dialekt/implementace dela po svem, nicmene situace neni az tak spatna, protoze se vytvoril urcity nepsany standard:
(a) Pouze explicitne globalne definovane promenne jsou viditelne mezi thready, tedy vytvorene pomoci defparameter/defvar (a mnohalety uzus je ze globalni promenne jsou zlo).
(b) Bindings, tedy promenne vytvorene pomoci let jsou thread local.
(c) Nove vytvoreny thread nededi bindings z parent thread.
(d) catch, unwind-protect etc. jsou take thread local.

Tedy cesta k reseni je deklarovat promenne jako sdilene mezi thready (globalni) a implementovat kupu maker kontrolujici ownership nebo pouzit implementaci umoznujici rebind promenne a presunout ji mezi thready, coz by byla cesta k obdobnemu reseni jako u Rustu. Zda se mi, ze Clojure neco podobneho uz umi (binding), ze ale nezkoumal jsem to. Osobne jsem si zatim vystacil se standardnimi thready v SBCL a lparallel, coz slusny balik parallelnich makrotriku. Limitace neni ve vlastnim jazyku, Lisp je dostatecne flexibilni, ale v podpore implementaci, protoze threading proste nelze implementovat ciste jako knihovnu a zatim se mi nezda ze by byla velka poptavka.

[kralyk z abclinuxu]

Ok, dík za odpověď.

V Rustu je ownership v podstatě záležitostí statické analýzy, což má výhodu zero-cost (a 'low-cost') abstrakcí, ale zase nevýhodu v tom, že statická analýza je omezená. Takže Rust má vlastně přesně opačný problém... Mj. např. stále ještě nemá pořádný tracing GC.

[little.owl]

Tak to zkuste pouzivat a pochopite.

[kralyk z abclinuxu]

Jaké cvičení by bylo vhodný na to, aby se v tom nějak ukázaly nějaké zajímavé vlastnosti toho jazyka?

[Bystroushaak]

Napsat si v lispu interpretr lispu. Je to dokonce tradiční úloha.

[kralyk z abclinuxu]

Uhh, nebylo by něco praktičtějšího?

[deda.jabko]

Co je nepraktickeho na pochopeni, jak funguje jazyk (nastroj), ktery pouzivas?

[kralyk z abclinuxu]

Mně zajímá, k čemu je ten nástroj dobrý. U Prologu nebo Befunge jsem taky rozhodně nezačínal meta-interpretem.

[deda.jabko]

Mně zajímá, k čemu je ten nástroj dobrý.

Prijde mi ponekud nemistne ptat se k cemu je dobry programovaci jazyk.

Jinak meta-interpreter je dobry na to, abys pochopil, jak ten jazyk funguje a jake ma vlasnosti, napr. uzavery a lexikalni rozsah platnosti se na tom vysvetluji moc dobre. A to vse na par radcich. Receno slovy klasika: Nechci se vas dotknout, ale ktery programovaci jazyk to ma?

[kralyk z abclinuxu]

Prijde mi ponekud nemistne ptat se k cemu je dobry programovaci jazyk.

Já se neptal k čemu je dobrý programovací jazyk, ale k čemu je dobrý tento programovací jazyk. Kdyby po mě někdo chtěl něco takového například v C++, tak bych se snažil najít třeba příklad nějaké vysokoúrovňové konstrukce, která kompiluje do rychlého kódu (což je imho silná stránka C++), v Rustu by to byl příklad ukazující borrow-checker nebo traits. V Pythonu jednoduchost syntaxe, dejme tomu. A podobně.

Receno slovy klasika: Nechci se vas dotknout, ale ktery programovaci jazyk to ma?

Ok, to je obviuhodné, že to Lisp, teď jen ještě kdybych teda věděl, k čemu to je dobré Já mam pocit, že třeba uzávěry a lexikální rozsah celkem chápu z ostatních jazyků.

[deda.jabko]

Já se neptal k čemu je dobrý programovací jazyk, ale k čemu je dobrý tento programovací jazyk.

K programovani. To je, jak ptat se k cemu je dobra Java nebo C#.

v Rustu by to byl příklad ukazující borrow-checker nebo traits.

To ale neni ukazka k cemu je ten jazyk dobry, ale co uvnitr pouziva.

V Pythonu jednoduchost syntaxe, dejme tomu. A podobně.

To opet neni odpoved na otazku, k cemu je ten jazyk dobry, ale jakou ma vlastnost.

Ok, to je obviuhodné, že to Lisp, teď jen ještě kdybych teda věděl, k čemu to je dobré

K cemukoliv, k cemu to programator potrebuje. Ja s nim treba chroustam data, protoze program i data splyvaji do jednoho, nemusim resit nejake nacitani XML, atp, proste vezmu data a nactu je do programu jako lispovy seznam) a experimentuju s DSL. Jini s nim delaji symbolicke vypocty. Jini vyuzivaji splyvani dat/programu k tvorbe expertnich systemu a veci z AI. Jini v tom delaji webovky (svuj web mam treba napsany ve Schemu, templatovaci engine je ve skutecnosti jednoducha sada funkci).

Já mam pocit, že třeba uzávěry a lexikální rozsah celkem chápu z ostatních jazyků.

Good for you. Ja jsem psal, o tom, ze se tak da jednoduse a rychle vysvetlit cely jazyk vcetne techto detailu.

[kralyk z abclinuxu]

Ja s nim treba chroustam data, protoze program i data splyvaji do jednoho, nemusim resit nejake nacitani XML, atp, proste vezmu data a nactu je do programu jako lispovy seznam) a experimentuju s DSL.

No vida, to už zní jako celkem pěkný praktický úkol...

[dumblob]

K cemukoliv, k cemu to programator potrebuje. Ja s nim treba chroustam data, protoze program i data splyvaji do jednoho, nemusim resit nejake nacitani XML, atp, proste vezmu data a nactu je do programu jako lispovy seznam) a experimentuju s DSL.

Casto vidam obdobny pristup u ruznych vyvojaru a pokazde si kladu otazku jak se v takovych pripadech resi error-handling ci ruzne chyby kvuli necistote prostredi (timeout TCP spojeni, chyba pri cteni z disku, chybna syntaxe, chyba v kontrole vuce DTD, a mnoho dalsich).

Nechme stranou takove to domaci programatorske pohravani si na vlastnim pisecku a mrkneme treba do nenavideneho sveta stredne velkych a obrovskych systemu (napr. "enterprise") plnych XML ruzne kvality a ruznych chyb. Mohl byste prosim v kratkosti popsat vyhody splyvani dat s programem v techto zcela serioznich a v IT zivote naprosto beznych pripadech? Ja za tech nekolik let co si tuto otazku kladu nebyl schopen prijit totiz ani na jednu vyhodu .

[little.owl]

Tak v prvni rade jde o integritu dat. Separace dat a programu je jedna z cest, jak ji docilit. Lisp tuto separaci umoznuje, homoikonicita tomu nebrani, ta predevsim rika ze data i kod maji stejnou reprezentaci.

Ohledne osetrovani chyb: LISP pouziva Conditions ("vyjimky") a Restarts, vcetne veci jako osetreni bez odrolovani stacku, viz. zde.

[dumblob]

Tak v prvni rade jde o integritu dat. Separace dat a programu je jedna z cest, jak ji docilit. Lisp tuto separaci umoznuje, homoikonicita tomu nebrani, ta predevsim rika ze data i kod maji stejnou reprezentaci.

Pokud jsem Vas spravne pochopil, pak splyvani dat a programu neprinasi zadne vyhody a predrecnik tedy vyuzival tuto moznost pouze na to domaci pohravani si na vlastnim pisecku.

Ohledne Restarts atd., po jejich pouziti jiz kod neni vubec pekny a cisty - degraduje to vyzdvihovany Lisp na uroven zcela srovnatelnou s dnesni tvrdou konkurenci.

[little.owl]

Pokud jsem Vas spravne pochopil, pak splyvani dat a programu neprinasi zadne vyhody a predrecnik tedy vyuzival tuto moznost pouze na to domaci pohravani si na vlastnim pisecku.

Nepochopil a asi ani predrecnika.

Jednodusi XML jdou nacist/zapsat primo do/z listu, coz je nativni typ Lispu pro data i kod a pak skutecne muzete zapomenout na XML.

[dumblob]

K cemu je tedy splyvani dat a programu v neakademickem IT svete dobre, kdyz nelze vyuzit dokonce ani na miniaturni zalezitosti typu konfigurace pro JWM (JWM ma kompletni konfiguraci v XML)?

[little.owl]

K cemu je tedy splyvani dat a programu v neakademickem IT svete dobre,

Pak by mozna bylo dobre ujasnit, co myslite pod pojmem 'splyvani'.

kdyz nelze vyuzit dokonce ani na miniaturni zalezitosti typu konfigurace pro JWM (JWM ma kompletni konfiguraci v XML)?

Proc by to nemelo byt mozne vyuzit a zrovna s timto programem?

[dumblob]

Pak by mozna bylo dobre ujasnit, co myslite pod pojmem 'splyvani'.

Myslim to, co deda.jabko popisoval v prispevku vyse, na ktery jsem reagoval:

K cemukoliv, k cemu to programator potrebuje. Ja s nim treba chroustam data, protoze program i data splyvaji do jednoho, nemusim resit nejake nacitani XML, atp, proste vezmu data a nactu je do programu jako lispovy seznam) a experimentuju s DSL. Jini s nim delaji symbolicke vypocty. Jini vyuzivaji splyvani dat/programu k tvorbe expertnich systemu a veci z AI. Jini v tom delaji webovky (svuj web mam treba napsany ve Schemu, templatovaci engine je ve skutecnosti jednoducha sada funkci).

Proc by to nemelo byt mozne vyuzit a zrovna s timto programem?

Protoze je potreba resit syntakticke vyjimky, chyby pri cteni z disku, chybnou strukturu stromu atd. Tedy pokud vyuziji homoikonicitu, bude kod vypadat prinejmensim tak seredne jako bez pouziti homoikonicity, protoze budu pouzivat Restarts, vyjimky, "signaly" atd.

[little.owl]

Protoze je potreba resit syntakticke vyjimky, chyby pri cteni z disku, chybnou strukturu stromu atd. Tedy pokud vyuziji homoikonicitu, bude kod vypadat prinejmensim tak seredne jako bez pouziti homoikonicity, protoze budu pouzivat Restarts, vyjimky, "signaly" atd.

Chapete vubec co to homoikonicita je a jake jsou jeji implikace?

Mechanismus osetrovani chyb v Lispu je ortogonalni a pouzity model je o neco flexibilnejsi nez klasicky try-catch-finally ci event-handler pristup. Serednost je subjektivni zalezitost a objektivni komplexita osetrovani chyb neni vetsi nez v jinych jazycich, osetrovani chyb programu neni vetsinou trivialni.

[dumblob]

Chapete vubec co to homoikonicita je

Tezko sebe hodnotit, protoze samozrejme bych rekl, ze ano.

a jake jsou jeji implikace?

Zrejme nedostatecne ano, a proto se na ne ptam s ohledem na realne vyuziti a zatim jsem obdrzel pouze stare dobre "jo, zadnou realnou vyhodu to nema" (pouze vyjadreno jinymi slovy). Coz neni nic spatneho. Proste nepekne a ukecane osetrovani chyb je neodmyslitelna vlastnost pri vyuzivani homoikonicity pro externi vstupy, nic vic.

Mechanismus osetrovani chyb v Lispu je ortogonalni a pouzity model je o neco flexibilnejsi nez klasicky try-catch-finally ci event-handler pristup. Serednost je subjektivni zalezitost a objektivni komplexita osetrovani chyb neni vetsi nez v jinych jazycich, osetrovani chyb programu neni vetsinou trivialni.

Ano, je flexibilnejsi nez uvedene a komplexita osetrovani je srovnatelna s lehce starsimi jazyky (navrhem). Napr. Google Go je vsak dal (defer) a jazyky s logickym paradigmatem jsou taktez napred. Tedy v takto tvrde konkurenci skutecne pouziti homoikonicity na vstupy silne zaostava.

[little.owl]

apr. Google Go je vsak dal (defer)

Identicke reseni lze postavit na unwind-protect a lze napsat i makra implementujici chovani defer/panic/restart, i kdyz by to byl spise krok zpet. Lze jit i dale, protoze lispovske Restarts umoznuji osetreni chyby bez odrolovani stacku a ztraty objektu ci dynamicke informace, a lze oddelit logiku ktera rozhoduje jak chybu osetrit a vlastni implementaci osetreni. Osetreni chyb v Go je primitivni a limitujici, ostatne jako temer vse v Go, uz treba jen proto ze v nekterych situacich fakticky nelze psat "exception safe code" a spojuji dohromady exceptions a error codes. Tedy, v cem je konkretne Go s defer dale?

Tedy v takto tvrde konkurenci skutecne pouziti homoikonicity na vstupy silne zaostava.

Nechapu co tim chtel basnik rici. Homoikonicita je vlastnost jazyka, ktera nijak neomezuje a jen dava moznosti navic. Znovu, v cem je problem?

[dumblob]

Tedy, v cem je konkretne Go s defer dale?

V tom, ze prave neumoznuje napr. jednoduse odrolovat zasobnik. Go si vybralo nektere z mnoha abstrakci (ktere lze vytvorit napr. v Lispu pomoci maker) a ty efektivne implementovalo (napr. osekany defer). Je to srovnatelne napr. s ASM versus C, kde C take zahodil mnoho moznosti rucnich hratek v ASM a poskytlo vyssi abstrakci.

A v tomto pripade povazuji implikaci jazyk poskytuje vyssi abstrakci by default => jazyk je dale za platnou.

Znovu, v cem je problem?

V pouzivani homoikonicity na zpracovani externich vstupu, jakkoliv toto muze zpocatku vypadat nadherne.

[kralyk z abclinuxu]

A v tomto pripade povazuji implikaci jazyk poskytuje vyssi abstrakci by default => jazyk je dale za platnou.

+1, něco takového jsem se snažil popsat tím defclass příkladem...

[little.owl]

V tom, ze prave neumoznuje napr. jednoduse odrolovat zasobnik.

Aha, Go je mnohem dal s defer, nebot neumoznuje jednoduse odrolovat zasobnik. Prestavam chapat argumentaci timto smerem, zejmena s ohledem na implementaci contiguous stacku v Go od verze 1.4+.

ty efektivne implementovalo (napr. osekany defer).

Defer v Go efektivni? Videl jste implementaci zde? Defer v Go neni deklarace, ale statement, ktery vytvari closure, kopiruje pro ni data, alokuje pamet v poolu a zamyka scheduler a to predtim nez se neco vubec stalo. Cely defer/panic/recover mechanismus ma nejen velky overhead, ale je nutne ho pouzivat v cele rade situaci, nebot v Go muze panikarit kde co a jiny mechanismus v podstate neni. Error handling v Go rozhodne neni vystavni kod.

A v tomto pripade povazuji implikaci jazyk poskytuje vyssi abstrakci by default => jazyk je dale za platnou.

Pak mi opet neni jasne v cem mate vyhrady. Osetreni chyb zalozene na Conditions/Restarts, tak je implementovan v Lispu, poskytuje naopak vyssi miru abstrakce, nebot jedna se o generalizovane vyjimky a flexibilita je zajistena uplatnenim principu Separation of mechanism and policy, tedy oddelenim toho co ma byt udelano a jakym zpusobem to ma byt udelano. Osetreni chyb postavene na unwind-protect volajici clean-up kod po opusteni bloku ma minimalni overhead.

V pouzivani homoikonicity na zpracovani externich vstupu, jakkoliv toto muze zpocatku vypadat nadherne.

Stale nechapu. Homoikonicky programovaci jazyk ma strukuru programu podobnou jeho syntaxi, coz umoznuje snadno transformovat kod i data stejnym zpusobem. Ale s tim jak se zpracovavaji data v programu z externich vstupu to nijak nesouvisi.

[dumblob]

Ad Go)

Zda se, ze kazdy z nas chape pojem vyssi abstrakce v programovacim jazyce jinak - ja jako peclivy vyber nekolika malo konstrukci provedeny primo autory jazyka, Vy zase jako zpristupneni velkeho mnozstvi nizkourovnovych konstrukci vcetne tech divocejsich (umoznujicich mj. modifikaci run-time samotneho jazyka).

Jinak ano, vim, ze defer v Go kopiruje pamet (a zamyka scheduler, ale samozrejme ne cely, nybrz pouze "defer" scheduler), ale take vim, ze tento overhead neni v realu tak podstatny a nenapada me zadna Go knihovna ci aplikace, ktera by na tento "nedostatek"/"feature" trpela. Jsem tez presvedceny, ze az se objevi poptavka po bleskurychlem defer, tak defer bude reimplementovan (obdobne jako se to deje s mnoha jinymi castmi Go). Mimochodem mnoho jazyku resi problem "zachycovani hodnot urcitych promennych" jako kompilaci do uzaveru, protoze to je pomerne rychle, zcela bezpecne a hlavne jednoduche reseni (napr. v Dao jsou navic jednoduche optimalizace, ktere se vyhybaji kompilaci do uzaveru, coz setri dost casu napr. v tight loops).

Separation of mechanism and policy je hezke a naskyta se otazka, proc jazyk toto oddeleni nevynucuje, nybrz pouze doporucuje. Dle meho nazoru by vysokourovnovy jazyk mel idiomaticke pouziti vynucovat. Lisp je z tohoto pohledu spise podobny ASM, tedy nizko-urovnovy.

Ale s tim jak se zpracovavaji data v programu z externich vstupu to nijak nesouvisi.

V realu souvisi az prilis, protoze to je presne to, co kazdeho napadne jako prvni a nejjednodussi vyuziti homoikonicity.

[little.owl]

kazdy z nas chape pojem vyssi abstrakce v programovacim jazyce jinak - ja jako peclivy vyber nekolika malo konstrukci provedeny primo autory jazyka, Vy zase jako zpristupneni velkeho mnozstvi nizkourovnovych konstrukci

Absolutne ne, do teto roviny to nesmyslne posouvate pouze vy. Abstrakce je zpusob jak se designove vyporadat s komplexitou problemu a ja od programovaciho jazyka pouze ocekavam, ze mi poskytne dostatecne mnozstvi nastroju mnou zvolenou abstrakci implementovat. Pokud programovaci jazyk zacne vynucovat jediny zpusob, je to naopak cesta do pr**le, protoze neexistuje jedine spravne univerzalni reseni a drive ci pozdeji to zkonci podivnymi workaroundy. Lisp dava programatorovi vedle standardni datove a ridici abstrakce navic syntaxickou abstrakci a umoznujici, jak bylo zmineno, treba implementovat DSL s libovolnou urovni abstrakce.

Separation of mechanism and policy je hezke a naskyta se otazka, proc jazyk toto oddeleni nevynucuje, nybrz pouze doporucuje.

Opet se v tom zacinam ztracet. Ted uz tedy neni problem mira abstrakce, ktera je fakticky vyssi nez u Go reseni, ale chybejici vynucovani necoho, co u Go implementace, ktera ma byt podle vas dale, neni. Podstatne je ze Lisp reseni dava programatorovi flexibilitu jak veci udelat a nebrani jinemu reseni, pokud je pro dany problem vhodne.

Dle meho nazoru by vysokourovnovy jazyk mel idiomaticke pouziti vynucovat. Lisp je z tohoto pohledu spise podobny ASM, tedy nizko-urovnovy.

Ne. Vy opet chaoticky michate dohromady nekolik veci, minimalne expresivnost programovacicho jazyka a obsah a implementaci standardnich knihoven.

Nechci se vas dotknout, ale oznacit jazyk, ktery nativne podporuje mimo jine dynamicke typovani, garbage collection (vynalez Lispu!), vice programovacich paradigma, vcetne first-class generickeho metaprogramovani na urovni jazyka, genericke funkce ci pomerne pokrocily dynamicky objektovy system (CLOS) jako nizkourovnovy jazyk a srovnavat ho s ASM, tak to vyzaduje slusny stupen ignorantstvi. Na nejnizsi urovni ma Lisp atomy (cisla, znaky, retezce, symboly, ...), na nejvyssi urovni abstraktni objekty z knihoven. Filozofie je takova, je jadro jazyka je velmi male, zbytek rozsiren pres flexibilni syntaxickou abstrakci. To ze programator ma k dispozici i nizkourovnove atomy pouze rika, ze Lisp podporuje i nizkourovnove programovani.

Defer/panic/recover je v Go implementovan na urovni standardni knihovny a pokusy implementovat alternativni framework konci na limitech jazyka, spojenych treba s channels (operator), kde to narazi i na nestabilni implementacni omezeni, ktera mohou byt v pristi verzi jina (ee fuj, fuj jazykove standardy ...).

Ale s tim jak se zpracovavaji data v programu z externich vstupu to nijak nesouvisi.

V realu souvisi az prilis,

Dobre, ilustrujte mi na priklade uziti homoikonicity na zpracovani dat z externich vstupu, treba onech dat ze site - prvni co kazdeho napadne.

protoze to je presne to, co kazdeho napadne jako prvni a nejjednodussi vyuziti homoikonicity.

Nebudte smesny, spise to posledni. Metaprogramovani zalozene na transformaci a generovani kodu vyzaduje specificky model mysleni, ktery si clovek nevytvori ze dne na den, a ktery lide prichazejicich z jinych jazyku, kde maximalne zavadi o limitovany template programming, proste nemaji.

[Bystroushaak]

+1

[kralyk z abclinuxu]

To zní všechno hrozně učeně a na úrovni, ale úplně si vyignoroval jednu užitečnou strategii: Optimalizaci pro běžný případ. Ostatní jazyky (ok, krom Javy) se typicky nesnaží naordinovat jedno konkrétní paragidma, ale svým návrhem prostě akorát optimalizují pro běžný případ. Ta 'konvergence k Lispu' u ostatních jazyků je pouze snaha vyřešit ty méně obvyklé případy. A vypadá to, že některým se to docela daří (imho třeba Scala). Lisp má přesně opačný problém.

Metaprogramovani zalozene na transformaci a generovani kodu vyzaduje specificky model mysleni, ktery si clovek nevytvori ze dne na den, a ktery lide prichazejicich z jinych jazyku, kde maximalne zavadi o limitovany template programming, proste nemaji.

Jo. Být náckem hajlujícím na stadioně taky vyžaduje specifický model myšlení, který ostatní, kteří tak maximálně sedí někde v kanclu, prostě nemají.

[kyknos]

tobe snad musel mccarthy prebrat zenskou...

[Bystroushaak]

To už jsme se dostali k Hitlerovi? To mělo podle mých propočtů ještě chvíli trvat.

[kralyk z abclinuxu]

To už jsme se dostali k Hitlerovi?

Ještě ne

[little.owl]

vyignoroval jednu užitečnou strategii: Optimalizaci pro běžný případ.

Nevyignoroval. Optimalizace je predevsim otazka implementace a Lisp standard dava pomerne slusny prostor pro specificke chovani s ohledem na "bezny pripad". To co je v jedne implementaci blok maker, muze byt v jine optimalizovana funkce napsana v assembleru, nektere veci jsou "optional" a nektere techniky se nedoporucuji. Tomu neunikne zadny jazyk.

Lisp má přesně opačný problém.

Lisp ma plno problemu, nikdy to nebyl mainstreamovy jazyk, ale fakt je ze tu skoro 68 let a stale o nem slysime, je uspech.

Jo. Být náckem hajlujícím na stadioně taky vyžaduje specifický model myšlení, který ostatní, kteří tak maximálně sedí někde v kanclu, prostě nemají.

To je velmi hloupe prirovnani - mozna ze i pres nej jste chytry a nemate problem ze dne na den zmenit paradigma, zacit v nem myslet a psat optimalni kod. Ale troufam si tvrdit, ze vetsina nas ostatnich, odkojena na prevazne imperativnich jazycich, s trochu funkcionalniho programovani, bude potrebovat cas.

[little.owl]

Ehm, 58 let, cas jit spat.

[kralyk z abclinuxu]

To co je v jedne implementaci blok maker, muze byt v jine optimalizovana funkce napsana v assembleru

Může, ale tím se tak trochu popře to, že veškerý kód jsou s-exprs (viz #72 nebo #78) a že interpret je na 90 řádků. To samé ten argument o CLOS - ten taky nebude na 90 řádků, že...

To je velmi hloupe prirovnani

To nemělo být ani tak přirovnání, chtěl jsem tím říct jen, že to, že něco vyžaduje jiný způsob myšlení, ještě neznamená, že to je lepší nebo že stojí za to myšlení měnit.

[little.owl]

Může, ale tím se tak trochu popře to, že veškerý kód jsou s-exprs (viz #72 nebo #78) a že interpret je na 90 řádků.

Znovu si prectete #72, kde jsem na konci psal:

Zbytek muze byt self modifikovatelny kod i kdyz v praxi je to omezeno na urovni standardni implementace z vykonostnich duvodu.

Lisp muze byt implementovan bud jako kompilator, interpreter nebo oboji, a kompilovana verze omezi dynamicke chovani. Jak bylo ilustrovano v #117, behem prekladu se analyzuje kod a pouziva se nejoptimalnejsi zpusob, a to nevyjima ani jadro standardni implementace.

To samé ten argument o CLOS - ten taky nebude na 90 řádků, že...

Nebude. Pointa byla v tom, ze pro implementaci Lispu vam staci napsat minimalni jadro v C/ASM/JS/Java ci cemkoliv jinem a zbytek samotneho Lispu muzete dodelat v Lispu samotnem, vcetne celeho CLOS. Takto je implementovan treba SBCL, kdy pouze runtime je implementovan v ASM/C, zbytek v Lisp, a i na urovni ASM/C se manipuluje s Lisp atomickymi symboly/s-expressions.

že to, že něco vyžaduje jiný způsob myšlení, ještě neznamená, že to je lepší nebo že stojí za to myšlení měnit.

Souhlasim, ale to prece neni co jsem psal.

[deda.jabko]

Nechtel jsem se teto casti diskuze ucastnit, protoze ty otazky jsou dost mimo, nic ve zlem. Ale sam jsi prisel na hezky priklad, kdy to jde pouzit.

Co tak tu konfiguraci zapsat misto XML pomoci S-vyrazu, ktere pujdou primo interpretovat? Treba takto:

(desktop-size 1024 768)
(bind key (alt f4) (close-window *active*)) ;; zavri aktivni okno
(bind key (ctl alt f4) (apply minimize (find-window "FireFox"))) ;; najdi vsechna okna obsahujici FireFox a minimalizuje

;; pomocna funkce (dokaze toto xml?)
(define (wine file)
  (exec "/usr/bin/wine" file))

(main-menu
   (item "FireFox" (exec "/usr/bin/firefox"))
   (menu "Office"
       (item "Word" (wine "C:\\Program Files\\Microsoft Office\\bin\Word.exe"))
       (item "Escel" (wine "C:\\Program Files\\Microsoft Office\\bin\Escel.exe"))
       ...))

V tomto pripade by se ve skutecnosti nejednalo pouze o nejake konfiguracni hodnoty, ale fakticky o konfiguracni prikazy, ktere by menili nastaveni aplikace. Vyhoda o proti XML je v tom, ze se nemusis omezovat na to, co ti autor pridchystal za moznosti do XML a muzes zkombinovat jednotlive casti API (funkci) do novych, zajimavejsich celku, dle libosti.

[dumblob]

Ano, psat konfiguraci primo v kvalitnim programovacim jazyce se nejen z mych zkusenosti ukazuje jako dlouhodobe nejlepsi reseni a urcite s tim souhlasim. JWM jsem uvedl umyslne, protoze jsem s autorem prave vyuziti S-expr pro konfiguraci kdysi resil.

Kazdopadne dotaz byl ohledne non-Lisp/non-S-expr konfigurace a cilem je zamyslet se nad (ne)vyhodami homoikonicity pro zpracovani jakychkoliv externich vstupu.

[kralyk z abclinuxu]

Co tak tu konfiguraci zapsat misto XML pomoci S-vyrazu, ktere pujdou primo interpretovat?

Na tomhle nápadu oceňuju nahrazení XML něčím rozumnějším. Tím to ale konči. Přímo interpretovat konfigurák mi přijde jako naprostá blbost, protože 1) člověk stejně musí reagovat na a ošetřovat syntaktické chyby, které uživatel udělá (a že je dřív nebo později udělá), 2) chyby uživatele mají potenciálně mnohem horší následky než u toho XML, protože mohou ovlivňovat program a 3) z bezpečnostního hlediska to je tragédie, viz třeba JSONp. Je samozřejmě otázka, jestli by to v dané aplikaci skutečně představovalo bezpečnostní problém, ale pravidlo palce je takové, že kód od uživatele pokud možno nespouštíme.

[Bystroushaak]

Na tomhle nápadu oceňuju nahrazení XML něčím rozumnějším.

To je imho do velké míry nemožné. Já byl docela XML hater, ale poté co jsem si o tom kvůli práci nastudoval víc literatury musím uznat, že cokoliv co by mohlo nahradit XML by skončilo úplně stejně komplikované. Možná by šla trochu vylepšit syntaxe, ale i u tohohle vcelku pochybuji, protože s-vyrazy by byly možná ještě o kus delší. Co dodneška nesnáším je javovský ekosystém kolem XML, ten by si fakt nahradit zasloužil.

[dumblob]

Do posledniho puntiku +1.

[little.owl]

Take v tom nevidim zasadni vyhodu, snad jen ze parsing a validace dat je pak velmi jednoducha, muzete tam primo vlozit kod (lze take validovat) a nepotrebujete xml knihovnu.

[little.owl]

Tezky pozadavek. Lisp jako jazyk je odlisny od standardnich mainstreamovych jazyku, takze i jednoduche priklady bez znalosti zakladu nebudou srozumitelne ani ilustrativni. Pokud skutecne chcete zacit s lispovskou rodinou, zacnete se Scheme a primocara kniha pro zacatek je The Little Schemer: 200 stran, jeden vikend a pro me byla i celkem zabavna.

[kralyk z abclinuxu]

Ok, dík, podívám se...

[PH]

Protože je jednoduchý a elegantní. Kuriózní je, že vlastně nevznikl jako jazyk.

Kdysi kdosi prohlásil, že všechny jazyky konvergují k Lispu. A víceméně to sedí.

[kralyk z abclinuxu]

Kdysi kdosi prohlásil, že všechny jazyky konvergují k Lispu. A víceméně to sedí.

Imho konfirmační bias. Ano, dají se najít vlastnosti nových jazyků nebo nových verzí starých jazyků, které tohle tvrzení podporují, ale stejně tak imho pozorujeme i vlastnosti tomu odporující. Viz třeba JS Harmony, ten jde imho opačným směrem. A v neposlední řadě to je imho vidět na Lispu samotném, novější & populární varianty Lispu, tj. mám na mysli hlavně CommonLisp a Clojure, jdou od původní minimalističnosti směrem ke klasickým jazykům.

[PH]

Rust teda žádný zázrak není, to už je mnohem zajímavější Go. Kdybych zrovna nedělal na projektech pro MIPS (satelitní přijímače), tak bych Go použil. Swift je zajímavý z akademického hlediska, ale pro produkční nasazení to rozhodně na Linuxu není.

[Sid]

ano go je naozaj zaujimavy hlavne ked chces ist smerom dole a mas tam gc.

[Radek Miček]

Rust teda žádný zázrak není, to už je mnohem zajímavější Go.

Go nemá generika (až na pár speciálních typů, které jsou integrovány přímo v jazyce) - je tedy téměř nepoužitelné. A to, jak je v něm implementován strukturální podtypový polymorfismus (kopírováním vtable), se mi také příliš nelíbí.

[little.owl]

Go nemá generika (až na pár speciálních typů, které jsou integrovány přímo v jazyce)

Pracuje se na tom a zatim nevedi jak to rozumne udelat.

je tedy téměř nepoužitelné.

Rekl bych ze plno projektu v produkcnim stavu napsanem v Go ukazuje ze to neni pravda.

[little.owl]

Ne. Swift neni akademicky jazyk a Apple ma dost velky ekosystem, aby byl schopen ho uvest v zivot, stejne jako Microsoft C#.

Rust uz je v podstate na stejne trajektorii jako jazyk D.

[kralyk z abclinuxu]

Rust uz je v podstate na stejne trajektorii jako jazyk D.

IMHO má lepší výchozí předpoklady - není to pouze re-engineering (resp. osobně bych spíš řekl re-over-engineering) C++ a od začátku má testovací zátěžový seriózní projekt (Servo), ale máš do jisté míry pravdu, bohužel to tak trochu vypadá.

[Hans1024]

Vyhody Rustu pro nekoho muzou byt nevyhody. Kdyz chce nekdo svoji myslenku rychle naprogramovat a nepotrebuje komplikovanou spravu pameti (clovek casto vidi, ze nedojde k problemu, zatimco kompilator to nevi), tak mu ten jazyk a kompilator akorat hazi klacky pod nohy.

[Sid]

mas pravdu, prave vyhoda rust-u je podla mna v tom, ze vacsina chyba v alokaciach a podobne veci vznika tak, ze mas integrovany kod a jednoducho nemas cas preliezt kde co sa deje takze velmi lahko mozes urobit kod co na prvy pohlad vyzera ok ale kedze v pozadi (kniznica,cudzi kod) sa robi nieco co netusis tak vysledok moze byt neocakavany. Rust jednoducho nuti oddelit tieto veci co sa mi pozdava specialne ked to ide bez pouzivania gc.

[Radovan]

Konečně důstojná náhrada za C++.

[PH]

Ještě bych nejásal, pořád to není "production ready". Navíc to je náhrada spíše za ObjC, C++ bude mít pořád svoje místo. Ale je fakt, že se v tom píše lépe a radostněji :)

[Rezza]

Jednu vec nechapu - to je low level jazyk pro Apple a na GUI aplikace maji neco nebo se v tomhle pisou i normalni telefonni aplikace? Kde se spis hodi veci stylu neco jako Swift dole a nahore QML.

[michi141]

Píše se v tom (stejně jako s Objective C) i GUI, ale není to „nutnost“ – dají se na něj používat XIB/Storyboardy (XML) klikatelný v Interface Builderu (součástí Xcode) s provázaností na properties controllerů v kódu.

[dumblob]

Radeji bych videl rozvoj napr. multiplatformniho jazyka Dao github.com/daokoder/dao, ktery krome strceni do kapsy Pythonu, Ruby, apod. aspiruje tez na nahradu Go nebo Javy. Knihovny jsou od zacatku nadherne navrzene a jedine co jazyku chybi je komercni vyuziti a podpora.

Kdyz uz je rec o Apple, tak stastlivcum, kteri vlastni iPhone (nepatrim mezi ne) doporucim rozjet testovaci 3D aplikaci napsanou v Dao, kterou pise sam hlavni borec z tymu okolo Dao.

[Bystroushaak]

Lol. Neschopnost přidat koncovku pro readme a expirovaná doména opravdu budí důvěru.

[dumblob]

Projekt na GitHubu je mirror Fossil repozitare na te expirovane domene (z toho vyplyva, ze se neda pouzit pull request na GitHubu). Velka uzivatelska zakladna Dao je v Cine a GitHub jiz byl nekolikrat po mnoho tydnu v Cine nedostupny (Great Firewall of China, github.com/greatfire/wiki), proto ten Fossil a proto bezne README bez koncovek.

Expirovana domena zrejme souvisi s tim, ze vedouci vyvoje (Cinan) je zase na nejakou dobu v Cine, kde ty Utazske servery na kterych daovm.net bezelo nemusi byt dostupne (to je snad poprve za tech 9 let co bezely; hosting byl zmenen jiz minimalne jednoukrat). Jsem presvedceny, ze az pominou uzaverky v ruznych firmach kvuli Vanocum, tak se vse zase vrati do starych kolejich, kdy vyvoj sel milovymi kroky kupredu kazdym tydnem.

Momentalne zrejme nezbyva nic jineho nez naklonovat zdrojaky, spustit make a pak si precist vygenerovanou HTML dokumentaci.

[Ivan]

A co treba tohle? Nemerle. Dneska vznika tolik jazyku, ze nema ani cenu se nejaky novy jazyky ucit. Navrh jazyka neni to podstatne, podstatne je dotahnout to do nejakeho pouzitelneho stavu.

[dumblob]

podstatne je dotahnout to do nejakeho pouzitelneho stavu.

Coz nastesti Dao je. Skoda, ze dnes jiz i skveli programatori hodnoti projekty podle krasy webovych stranek :(

Ohledne jazyka Nemerle, tak skoda, ze vychazi z bajtkodu CLI, protoze ten je prilis omezeny a diky tomu virtualni masiny nepodporuji napr. zcela nezavisle paralelni zpracovani. Jinymi slovy se jedna o dalsi omalovanku, ktera skonci na urovni C#/Javy a nikdy nevybehne z uzavreneho boxu narozdil napr. od Dao.

[Bystroushaak]

Coz nastesti Dao je. Skoda, ze dnes jiz i skveli programatori hodnoti projekty podle krasy webovych stranek :(

Já tedy nejsem skvělý programátor, takže nehodnotím podle krásy, ale podle nekonzistencí. Působí to prostě sloppy a ne důvěryhodně na něco, co po mě chce takové životní rozhodnutní, jako věnovat čas a energii programovacímu jazyku, který mě potom má třeba živit.

[Bystroushaak]

Ostatně programování v něčem je jen tak z 60% o jazyku a ze zbytku o komunitě, jak se stará, jaký má přístup a jaké vyrábí nástroje a knihovny.

[Sid]

presne toto by malo byt vytesane do kamena. K comu je super jazyk ked neexistuju pouzitelne kniznice na vacsinu beznych veci (a najlepsie ked problem obcas riesia roznymi sposobmi). Podla mojho nazoru trocha horsi (aj ked to je relative co je horsi lepsi v jazykoch) + vyborne kniznice > lepsi jazyk + priemerne kniznice. (tj. nieco existuje, nieco je tak na pol ceste ked to vie iba to co autor aktualne potreboval)

[dumblob]

Pokud se budeme bavit o Dao, pak cely ekosystem Dao stoji samozrejme na poradne a kvalitni sade knihoven a modulu (od miniaturnich jako hratky se serializaci az po velke hracky jako web server):

• github.com/daokoder/dao-modules
• github.com/daokoder/DaoSQL
• github.com/daokoder/DaoCXX
• github.com/daokoder/DaoJIT
• github.com/daokoder/daostudio
• github.com/daokoder/dao-tools
• github.com/daokoder/DaoGraphics
• github.com/daokoder/DaoSDL
• github.com/daokoder/DaoGSL
• github.com/daokoder/DaoOpenGL
• github.com/daokoder/WebDao

A mnohe dalsi. Pokud by to bylo pro zacatek malo, tak lze za minutku nechat vygenerovat bindingy pro jakoukoliv jinou knihovnu s API v C/C++.

[Sid]

ono prave s bindingom sa akosi straca caro :). Vsakze nakoniec je lepsie mat aspon toto ako nic. Ale k zaporom : 1) V pripade portovania na iny system napr (typicky napr Linux/Windows) musite si prekompilovat aj vsetky kniznice v C,C++, co znamena v niektorych pripadoch dost solidnu stratu casu ak neexistuje priama podpora pre kompilaciu (nehovoriac o tom, ze chcete napr kompilovat pod VS) 2) Ak okolo bindingu neexistuje aj rozumny wrapper tak v pripade zlozitejsich kniznic sa nejako straca vyhoda toho ktoreho "super" jazyka

[dumblob]

Predpokladam, ze reagujete na posledni vetu, kterou jsem uvedl pro pripad, kdyby se nekdo ozval, ze ve standardni knihovne ani existujicich rucne psanych bindingach nevidi podporu pro svoji oblibenou knihovnicku.

Pro takove to bezne zvykani (napr. proflakla webarina) totiz staci z tech desitek dostupnych modulu treba pouze 5, a to se bavim o napojeni na existujici enterprise systemy a dalsi "veci navic".

ad 1) standardni knihovna se musi na kazdem podporovanem systemu pred pouzitim zkompilovat (stejne tak jako samotna virtualni masina) - nechapu tedy proc by to mel byt zapor, kdyz se jedna o zcela standardni a jediny zpusob jak toho docilit

ad 2) jiste, a proto take existuje standardni knihovna a rucne udrzovane moduly; automaticke generovani se hodi v pripade, ze nedava smysl knihovnu nejak obalovat (typicky treba zabehnute numericke knihovny, kde by obalovani zcela zbytecne matlo a neposkytovalo temer zadnou pridanou hodnotu)

[Sid]

Ad 1) skuste si napr.kompilaciu v8 enginu na windows pre vs plus ju trocha ohnut ohladom a uvidite co som myslel. Stupidnejsi system na kompilaciu som snad este nevidel. Neviem co myslite virtualnym strojom, bavime sa o tom istom? Este by som dodal, ze casto nejaka sikovna kniznica napr neni portovana, alebo sa ani neda prelozit lebo prekladac je o generaciu inde ako potrebujete.

[dumblob]

Otazka, zdali se bavime o tam samem je myslim na miste. Dao je momentalne interpretovany jazyk (o kompilovane variante "nesmim" mluvit, abych nematl potencialni uzivatele). Pro kompilaci interpretu Dao (virtualni masiny - VM) potrebujete C99-compliant kompilator. Toto je jedina podminka pro zkompilovani jak VM, tak i standardni knihovny vcetne vsech modulu.

Co tedy myslite kompilaci v8 enginu? To se standardni knihovnou a moduly nesouvisi.

[Sid]

Mysl, ze sme sa mierne nepochopili. To co som cely cas rozvadzal sa tyka bindingu. Tj prelozit napr c zdrojak niekde na cielovej platforme kde sice mate vo vasom pripade VM ale uz nie kniznice na ktore mate binding.

[dumblob]

Srozumeno. V tom pripade se tedy tento problem s multiplatformni kompilaci knihoven, pro ktere lze automaticky vygenerovat bindingy, vubec netyka Dao, nybrz clovicka, ktery bude potrebovat vlastni bindingy pro tyto obskurni knihovny.

[dumblob]

Plne to chapu a dokonce souhlasim. Dao je jedna z tech nekolika vyjimek, kdy se skvela vec jeste nedostala do sirokeho povedomi. Schvalne takove projekty vyhledavam a pote o nich sirim povedomi.

V takovych pripadech dam ruku do ohne za to, ze seznamit se s nimi (tedy venovat jim cas a energii) je velky prinos do budoucna. U Dao tomu neni jinak.

[melkors]

Nechci malovat certa na zed, ale kolik skvelych projektu, ktere skoncily "v kosi" jsme jiz videli?

[dumblob]

Nevim jak Vy, ale osobne si momentalne nevybavuji zadne, ktere skoncily "v kosi". Mam totiz extremne vysoko nasazenou latku pro privlastek skvely. U vsech projektu, ktere oznacuji za skvele soudim dle rustu komunity okolo nich a celkove prosperity (vcetne rozsirenosti pouziti), ze se ubiraji presne opacnym smerem nez ke kosi.

Skoda jen, ze techto skvelych projektu znam strasne malo (mene nez 10) a to kazdy tyden jiz po dobu nekolika let travim pravidelne nekolik hodin aktivnim vyhledavanim "zapadlych genialnich pocinu".

[Rezza]

"zapadly genialni pocin" je ten problem, na ktery tady lidi poukazuji.

[kyknos]

Zas na druhou stranu, lepsi zapadly genialni pocin, nez naopak (systemd, gnome3, php, java...)