...
K bodu 5: Souhlasím s tím, že párování závorek pomůže "rozšifrovat" zdrojový text, nicméně to neznamená, že se tím program stane výrazně čitelnějším. Čitelnost znamená "kouknu se a vidím" a ne "otevřu si editor, jezdím kurzorem sem a tam a hledám".
char*x(char*s,int c){char*r=0;while(*(*s-c?s++:r=s++));return r;}
Kouknu a vidím není vlastností jazyka, ale vlastnost konkrétního programu a programátora. Funkce x kterou uvádím pro pobavení je napsaná v jazyce C, který syntaktický cukr obsahuje, přesto není na první pohled vidět, že je ekvivalentní jedné standardní knihovní funkci.
K bodu 6: Prefixová notace sice má svoje výhody, ale zrovna u aritmetických operací a podobných akcí to prostě je handicap. Výhody existují, ale například násobnou aplikaci operátoru lze v jiných jazycích vyjádřit pomocí fold/reduce. S problémem infixových funkcí si z jazyků, které jsem viděl, asi nejelegantněji poradily Haskell a Scala.
Je to podobný typ handicapu jako to, že v Pascalu je pro tisk výstupu procedura write/writeln, zatímco v C je to funkce printf/puts/fputs/fwrite/..., v C++ operátor << na ostreamech, v jazyce Java je to metoda print/println atd. Je to jen nezvyk a nechuť učit se nové věci.
Zkrátka a dobře, vždycky je to něco za něco. Obrovská flexibilita LISPu je výhoda, o tom není sporu. Problém "metajazyků" typu LISP je dvojí:
1. Zhoršená čitelnost kvůli jednoduché syntaxi - syntaxe LISPu je computer friendly a ne human friendly. Syntaktický cukr je z hlediska čtenáře kódu výhoda, ne že ne.
2. Rozšiřitelnost a určitý paradigmatický agnosticismus (proč je, u všech všudy, potřeba do LISPu přidávat další a další konstrukce?) tento problém ještě zvětšuje.
1. Jde jen o zvyk. Když jsem přešel z Pascalu na C, tak mi přišlo { a } místo begin a end podobně nepřátelské. Dokonce jsem si myslel, že na = a == místo := a = si nikdy nezvyknu.
Příčinou zdánlivé nečitelnosti je jen nezvyk a nechuť učit se nové věci.2. Proč v okamžiku kdy je potřeba zpracovávat text programátoři raději sáhnou po Perlu než po C? Protože v Perlu je práce s řetězci pohodlnější a snazší. Proč? Protože má Perl specializované konstrukce pro regulární výrazy a programátor se nemusí starat o to, aby pro řetězec naalokoval správný počet bajtů. Kdyby byla jedna sada syntaktických konstrukcí vhodná pro všechna použití, tak by nebyly potřeba různé jazyky, stačil by INTERCAL. Lispeři na to jdou z jiného úhlu než jiní programátoři. Když mají problém, u kterého si řeknou: pro zjednodušení práce by se mi hodil jazyk, který má konstrukce A, B a C, tak si konstrukce A, B a C dopíšou do svého standardního překladače. Když je před stejný problém postaven programátor v jazyce C, tak buď si ty konstrukce doplní tak, že napíše jiný překladač (yacc, lex). Nebo, pokud se nepodaří oddělit ty konstrukce do nějakých separátních modulů jako v případě yaccu a lexu, tak napíše překladač pro nový jazyk (Perl). No a konečně pokud není dost zdatný na psaní překladačů, tak práci toho překladače vykonává ručně a místo toho, aby mohl používat nějakou konstrukci typu match(/regex/,string), tak volá příslušné funkce regcomp, regexec, regerror, regfree v pořadí a s argumenty, které by dokázal doplnit překladač automaticky.