Názory k článku
Omezuje prastaré ASCII dnešní programátory?

OMG, WTF?

Rekneme, ze bysme se zbavili textu (at uz ASCII nebo unicode) jako vyrazoveho prostredku pro psani programu a misto toho pouzili nejake abstrahovane symboly (konec koncu, prekladac ten text stejne musi prechroustat na neco pouzitelnejsiho). Zobrazeni kodu by pak bylo plne v kompetenci editoru a z prekladacu by se dala vyhodit cast syntakticke analyzy. Zmizely by problemy s tim, ze nekdo pouziva jine formatovaci znaky (whitespace, odradkovani, etc). Diff by nebyl rozdilem mezi dvema kusy textu, ale mezi dvema retezci symbolu, ktere maji /vyznam/ -- tim by se taky dalo z kodu vytahnout lepsi statistiky. Text by pak uz byl urcen jen pro skutecne retezce a pro editor, aby se s nim dalo domluvit pomoci klavesnice.

Doufam, ze se toho dockam a nebudu to muset udelat sam :P

s/syntakticke/le­xikalni/ samozrejme :)

"Zobrazeni kodu by pak bylo plne v kompetenci editoru a z prekladacu by se dala vyhodit cast syntakticke analyzy."

Takové nápady tu už byly. Má to podstatné problémy:
* můžeš použít jen jeden editor pro daný jazyk
* přijdeš o možnost automatické úpravy kódu --- např. ve vim, emacsu nebo třeba i ms wordu si můžeš psát makra --- jenomže jak si napíšeš makro ten tvůj editor pracující se syntaktickým stromem?

proč by nemohlo být makro taky jako syntaktický strom?

a vůbec, co dělá porucha, BLEKU?

Makro může pracovat nad syntaktickým stromem ... jen se ti to makro bude pak mnohem hůř psát.

Poruchu osobnosti mi diagnostikovala psycholožka, již brzy tomu bude 8 let, co žiji s diagnostikovanou poruchou :-(

Nebude, to je typicky omyl nekoho, kdo nezna Lisp (a nekoho, kdo vidi zapis makra, a divi se, k cemu jsou vsechny ty zpetne apostrofy a carky).

Jina vec je codewalking, ale to uz je opravdu slozite; nastesti to neni az tak potreba.

cast tohoto problemu resi treba fortress pomoci stylesheetu. kod lze psat i v ascii i s vyuzitim specialnich znaku, aby se kod vice podobal matematickemu zapisu. v podstate se jedna jen o ruzna zobrazeni daneho programu, takze lze mezi jednotlivymi mody jednoduse prepinat a je na editoru, ktere zobrazeni si vybere.

MPS :-)

Jak uz pise deda.jabko, typicky javovy overengineering. A jak uz dole pise Biktop, kazdy, kdo vymysli novy jazyk, by se mel podivat, zda to co chce uz neumi Common Lisp.

No jo, když proti lispovým makrům se prostě nedá argumentovat :-)

Tohle je, aspoň jak to chápu já, pokus dostat psaní "překladačů" na trochu vyšší stupeň abstrakce -- namísto gramatik, atributovaného překladu, tabulek symbolů atd. se vytváří komponovatelné "koncepty"... Prostě takový mírný pokrok v mezích zákona.

Lispaři musí pochopit, že mainstreamové jazyky sice konvergují k Lispu, ale nikdy se jím nestanou :-)

Opravdu stupidni clanek plny nesmyslu:

Nikdy sem si nevsiml ze by programatory omezovalo "ASCII". Existuji jazyky ktere pouzivaji hodne specialnich symbolu, existuji ty ktere jich pouzivaji mene, ale vesmes to s kvalitou kodu nebo prehlednosti nema temer zadny vztah. Ze by to snad dokonce byl nejaky existujici "problem", nebo stret nejakych programatorskych skol "ascii" a "unicode" sem si zatim nevsiml.

Opravdu je tady nejaky clovek co se zivi programovanim a mysli si ze ma moc malo specialnich znaku a chtel by jich vic? Ja tedy rozhodne ne.

Je mnohem vice faktoru, ktere programatora omezuji, a jsem si jisty ze pokud nekdo vidi "velky" problem v tom ze nemuze pouzivat unicode znaky ve svem oblibenem programovacim jazyce, asi se nudi a nevi roupama coby.

Mam pocit ze mnohem vetsi problem nez nedostatek ascii znaku je spis zacyklenost programatorske komunity v C/C++/Java/PHP jazycich, z cehoz plyne velka vetsina problemy s jazykem - a to je jeho mala expresivnost. A to je problem i GO.

Navic neprotireci si autor nahodou kdyz na jedne strane chce unicode znaky a na druhe strane se mu nelibi C-ckove operatory "|" a "&" ?

Na zaver meho rozhorceneho vylevu si dovolim citaci:

"Dokonalosti neni dosazeno, kdyz uz neni co dalsiho pridat, ale kdyz neni co ubrat"

osobně jsem pro programovací jazyk, který si vystačí s alfanumerickými znaky a mezerou no, možná bych z klíčových slov odstranil ta, která obsahují y a z abych se nemusel trápit na české klávesnici. Osobně mě otravují znaky, které jsou v každém layoutu klávesnice jinde.

A taky vyhodit Q, W, A, aby to neznepříjemňovalo život francouzům. A co pro jiné národy? Zrušíme všechny znaky?
Co vám brání používat layout který vám vyhovuje? Jste programátor a neumíte si změnit/upravit layout?

whitespace ! :-D

A taky odstranit l a O, casto se pletou s 1 a 0... ;-)

S křížkem po funuse. Tohle už zrealizoval Chuck Moore před 10 lety. ;-) V jeho ColorForthu je číslo syntakticky odlišeno jinou barvou, proto jednička a nula jsou zbytečné a používá se zde pro ně velké I a velké O, podobně jako kdysi na psacích strojích.

Zkuste si najít "DEC Alphabet" a zjistíte, že ani pan Moore zde nebyl žádným průkopníkem.

Ja bych symboly snad i vyuzil, ale opravdu chci psat treba + v krouzku na US klavesnici? Nechci, mne C++ syntax velice vyhovuje a dokazu v ni rychle napsat to co mam v hlave.

Jinak k male expresivnosti jazyka... nejsem si jistej jestli to spravne chapu (ze slovniku cizich slov "Význam: upřímnost, otevřenost, autentičnost, osobité vyjadřování skutečného prožívání").
Ale prijde mi to ze bud myslite moznosti prepisu myslenek do jazyka a tudiz vam C++ rodina jazyku prijde malo bohata na vyrazivo, ja bych v takovem pripade mluvil o abstrakci. A v takovem pripade treba pro mne osobne je C++ na hrane toho co umim vyuzit (ani to ne na 100%), jazyky ktere umoznuji bohatsi vyjadrovani nebo komplexnejsi operace (python, JS) mi delaji problemy a stejne nakonec vyuzivam jenom malou cast jejich potencialu, protoze ten zbytek mi proste vysumi z hlavy a vsechno nakonec zapisu pomoci male zakladni mnoziny z daneho jazyka. Mozna je to pozustatek dob assembleru, ze kdyz neco delam, tak automaticky premyslim jak to CPU bude pocitat, mozna je to jenom moje omezenost a zpusob premysleni. Tak jako tak verim ze existuji lide kterym by naopak vyhovoval mnohem abstraknejsi programovaci jazyk kde je napsat mnohem vice veci jednoduchym zapisem, ale mne by to spis matlo, nez ze by mi to umoznilo pracovat rychleji.

Nebo jste to myslel tak ze to malo vyjadruje to co se opravdu deje na CPU... v takovem pripade doporucuji ASM (muj oblibeny jazyk v kterem jsem toho napsal hodne a dela se mi v nem velmi prijemne, jenom skoda ze s produktivitou prace to nakonec prece jen bylo horsi).

A jak se to teda jinak řeší než přes templates?

Představ si, že chceš udělat kontejner, do kterého chceš cpát objekty určitého typu a pak je zase vybírat.

Můžeš do toho cpát void * pointery jako v C ... pak ti hrozí, že to špatně přetypuješ při výběru objektu z kontejneru a bude se to chovat nespecifikovaně.

Můžeš do toho cpát objekty v dynamicky typovaném jazyku jako Pythonu, ale pak opět hrozí, že při výběru objektu ho přetypuješ na jiný typ než co jsi tam vložil, a spadne ti to na exception.

A nebo uděláš C++ šablony, a pak ti už kompilátor sám typy zkontroluje, jak při vložení objektu do kontejneru, tak při jeho výběru. Kdybyses v C++ pokusil vybrat z kontejneru jiný typ než jaký jsi tam vložil, tak se ti to nezkompiluje (na rozdíl od výše popsaných jazyků, které se zkompilují a spadnou při běhu).

Pokud tvrdíš, že tento problém kontejnerů jde řešit líp, tak popiš, jak bys to řešil v Common Lispu (nebo jiném jazyce), aby docházelo k compile-time kontrole typů.

Z pohledu Lispare je staticka typova kontrola nejspis pritez. I kdyz Lispovemu kompilatoru lze teoreticky rict, jake hodnoty ma ocekavat, a on pak typovou kontrolu provadi, neni to stoprocentni, protoze filozofii Lispu je, ze hodnoty, nikoli promenne nesou typ.

Takze teoreticky by se to dalo resit pomoci kompilacnich nebo reader maker (coz je trochu magie), ale moc prakticke to neni.

Uvazuji o vlastnim jazyce (podobnem na Lispu), kde by tohle (castecne) mozne bylo, ale zatim je to v nedohlednu, takze to nebudu rozebirat.

Rikam castecne, protoze mi typova kontrola kontejnerovych typu prijde jako klesajici vynosy. Kdyz pak totiz definujete rozhrani metod k takovemu typu, musite u kazde metody oznacit, co je ten typ, kterym to parametrizujete. Tim se ale zaroven trochu strilite do nohy, protoze vam to komplikuje psani funkci, ktere pracuji s obecnymi algoritmy nad takovymi typy. Podle me jsou s parametrickymi typy fundamentalni problemy. Ale mozna se pletu, a v jazycich, ktere se to pokouseji nejak resit, jako Scala nebo Haskell se to nakonec podari pouzitelne udelat.

Mně přijde jazyk bez typové kontroly jako docela nebezpečný. Mnohokrát jsem v C napsal něco jako:

if (chyba) {
        fprintf("chyba cislo %d\n", chyba);
        exit(1);
}

Ti lidi, co zde píšou, jak nové programovací jazyky jsou blbost a jak všechno bylo vymyšleno v LISPu či Forthu ... jak oni vlastně řeší tento příklad --- kdy dojde k nesouladu typů na větvi programu, co se běžně nevykonává?

To píšou unit testy na všechny větve? Nebo mají tak bystrý mozek, že takovouhle chybu nikdy neudělají? (nebo v tom jejich jazyce píšou tak malé programy, že na tento problém nenarážejí? :) )

C++ templates jsou dost komplikované, ale nenapadá mě, jak ten problém statické typové kontroly řešit lépe a elegantně. Napadá to tebe?

Milý BLEK.u, zkus se někdy přemoci a zkus se třeba na ten Lisp pořádně podívat - ber to jako výzvu, zkus se vykašlat na všemožné předsudky, zkus nesrovnávat s jinými jazyky, prostě zkus ho pochopit coby matematik - kterým jakožto matfyzák aspoň trochu musíš být. Nepřemýšlej, jak bys takový a takový konstrukt jazyka C udělal v Lispu - zamysli se nad tím, jak bys daný problém řešil prostředky Lispu. Já vím, je to těžké, zvlášť když má člověk za sebou tisíce a tisíce řádků v C... Jazyky jako Lisp a Forth jsou skutečně značně odlišné od C - a to říkám jako člověk, který začal BASICem, prošel Assemblerem (v němž dělám dodnes), přes Pascal se dostal k C a C++, s nimiž jsem se potýkal minimálně 15 let (dnes už tolik ne) a jakýmsi řízením osudu se dostal k Lispu i k Forthu, kteréžto jazyky jsem z počátku nenáviděl - až do té doby, než jsem se naladil na myšlenkové pochody jejich tvůrců. A přesně u tebe vidím ty samé problémy, jaké jsem nastiňoval já kdysi - co když budu potřebovat do takového a takového kontejneru... co když budu chtít zkontrolovat typ toho a toho... No jasně - pokud k tomu člověk přistupuje takto... ale to je špatně! Člověk se u takovýchto jazyků musí dostat do situace, kdy si řekne "ale já nepotřebuji matlat se s nějakými kontejnery, já nepotřebuji matlat se s typovou kontrolou. Protože já celý ten problém můžu rozlousknout z úplně jiné strany a úplně jinými prostředky." K opravdovému pochopení jazyků jako je Lisp či Forth musí člověk zvyklý na algolské jazyky totálně překopat své myšlení, totálně překopat svůj pohled na to, jak má vypadat program, na to, co jsou data, co jsou algoritmy a na jakých úrovních spolu mají interagovat. Objektové programování je jen slaboučký odvar toho všeho - čehož důkazem mimo jiné je i to, že do obou zmíněných jazyků se dá OOP doprogramovat čistě jen prostředky těch jazyků - a tím nemyslím našvindlovat, jako třeba u C, ale skutečně doprogramovat, tj. vytvořit ideální syntaktické prostředky pro tento styl programování.
Běžný postup třeba u Pascalu nebo C při návrhu programu je analýza, návrh datových struktur a návrh operací nad těmito strukturami. To platí jak u strukturovaného, tak u objektového návrhu. U Lispu nebo u Forthu to tak ale není - tam po analýze následuje návrh lexikálních prostředků vhodných k řešení daného problému. A teprve v rámci těchto lexikálních prostředků se navrhují datové a algoritmické vazby. Jsou to vlastně metajazyky. Jestliže chci udělat databázi, nejsem omezen jen na záznam v kombinaci s polem nebo ukazatelem na tento záznam a standardní typovou kontrolou jazyka. Dotvořím si k tomu kus jazyka, kde k vlastnímu záznamu složitých dat bude použita úplně elementární entita - jako třeba spojový seznam nebo spojový seznam spojových seznamů, ale to, aby se s tím dalo elegantně pracovat, mi zajistí potřebná makra a funkce nad těmi makry už s tím budou operovat jako s elementy jazyka.

No a k těm dotazům - v podstatě jsi ty odpovědi trefil. Když píšeš v Lispu makro nebo funkci, ve Forthu slovo - tak hned jak ji napíšeš, tak si vyzkoušíš, jak funguje. Ty entity co vytváříš jsou tak jednoduché, že se to dá dělat - několikastránková funkce v C není neobvyklá - v Lispu nebo ve Forthu je to nesmysl, autor by se v tom začal ztrácet ještě v průběhu jejího psaní. Když dostaneš za úkol napsat algoritmus na výpočet determinantu matice řádu 3 Sarrusovým pravidlem, uděláš to v C jedním polem 3x3 a jednou funkcí. Ve Forthu to jedním slovem zaručeně dělat nebudeš - budeš si muset nějak syntakticky ztvárnit tu matici a nějak si elegantně zpřístupnit její obsah. Nakonec zjistíš, že tvoje myšlení je takovýmito jazyky tak z(de)formované, že až budeš dělat zase v C, tak tu chybu fakt neuděláš nikdy. A do třetice - opravdu děláš programy (nebo spíše komponenty) tak malé, že na tyto problémy nenarážíš, jelikož ten problém řešíš v těchto jazycích inkrementálně - asi jako bys někomu vysvětloval matematiku: neřekneš mu, co má udělat, aby spočetl to a to; vystvětlíš mu, co je to a to, jak se s tím pracuje, na základě této znalosti vysvětliš další věci atd. až dotyčný získá znalosti k výpočtu.
Tyhle jazyky tě nutí řešený problém nejdřív perfektně poznat. Jsou jako bystří studenti - když jsi mimo, tak tě dostanou a donutí pěkně si nabít hubu; když víš o co jde, tak ti dokážou pomoci při nalezení správného řešení.

To by mě dost zajímalo, ukaž mi někde příklady, které se dají špatně řešit procedurálními jazyky a dají se dobře řešit LISPem? V neprocedurálním programování ve škole jsem se totiž nenaučil nic (úlohy typu: "napište tento algoritmus v tomto neprocedurálním jazyce", což ovšem trvá dýl než bych ho psal v procedurálním).

Na internetu člověk o LISPu najde spoustu chvalozpěvů (nějaké dokonce přirovnávají LISP k Maxwellovým rovnicím: http://www.arcfn.com/2008/07/maxwells-equations-of-software-examined ), ovšem nepodepřených nějakými reálnými argumenty, proč by v tom bylo programovat lepší.

A programy těchto jazycích prakticky nejsou vidět (napadá mě leda Sparc konzole ve Forthu a psycholog v LISPu v Emacsu).

ten odkaz jsem dal špatně, správně má být http://www.arcfn.com/2008/07/maxwells-equations-of-software-examined.html

"Když dostaneš za úkol napsat algoritmus na výpočet determinantu matice řádu 3 Sarrusovým pravidlem, uděláš to v C jedním polem 3x3 a jednou funkcí" .....
Vím, že se to do této debaty nehodí, ale Jak se ten algoritmus zapíše v C++? Dík

Dal jsem si cas na rozmyslenou (a tajne doufal, ze odpovi nekdo za me, jak to pekne udelal Biktop), a uznavam, ze staticka typova kontrola muze nekomu chybet. Slo by trivialne namitnout, ze ten problem ale stejne neresi, protoze i kdybychom tam ten file handle meli, nemuzeme mit jistotu, ze ten soubor bude napr. otevreny.

V Common Lispu by tohle ale nebyl az takovy problem, protoze tento kratky kus kodu bychom zabalili do funkce (nebo do makra, pokuc bychom nechteli z duvodu vykonu pokazde vyhodnocovat argumenty), takze bychom ho snadno odladili zvlast. Ah, moment, ono uz to vlastne funkce je - jmenuje se error. A druha vec je, ze Common Lisp ma restarty a REPL, coz by usnadnilo reseni takoveho problemu.

Nicmene, vzpomnel jsem si na poznamku v knize Paula Grahama ANSI Common Lisp, kde srovnava Cckove a Lispove funkce. Tim, ze Lisp ma uzavery a funkce s obecnymi argumenty (tj. bez typove kontroly) dovoluje psat funkce ktere pracuji s funkcemi. Je IMHO zatim nevyresena otazka, zda takove veci vubec ve staticky typovanem jazyce jdou. A podobne problemy jeste vetsiho rozsahu maji typovane kontejnery.

Ptas se, proc to zkusit. Me presvedcila prednaska Practical Common Lisp, zejmena pak restarty. Precetl jsem si pak stejnojmennou knizku, a bylo to podnetne. Pro priklady veci, ktere nejde dobre udelat v C doporucuji knizku On Lisp a pripadne Let Over Lambda.

Hm, jeste nad tim premyslim, a skutecne, je to problem.

Filozofie C je, ze promenne maji typ, kdezto filozofie Lispu je, ze hodnoty maji typ.

To prvni prinasi moznost staticke typove kontroly, ale zabiji to moznost existence obecnych operatoru, protoze jak vypocitate vysledny typ? Ve finale se podle me nekde nemuzete vyhnout pretypovani.

To druhe sice bere moznost urcite staticke typove kontroly, ale zaroven vam to dava do ruky metaprogramatorske techniky.

Takze asi to bude, co si vybrat. Samozrejme, ten kdo metaprogramovani nezkusil, tomu asi nechybi, ale soude podle tvrzeni lidi, co znaji oboji, ozelite radeji to prvni.

Co jsem do té knihy koukal ... mně LISP přijde spíš jako write-only jazyk určený pro snadné řešení problémů, a ne jako jazyk určený pro psaní aplikací.

Silný makrojazyk ... nepřijde mi to jako výhoda pro psaní aplikací. Příklad: v Linuxu třeba najdeš volání funkce outb_p. Nicméně definici té funkce tam v arch/x86 nenajdeš. Nenajdeš ji proto, že je generovaná makrem a i její jméno je také poskládáno makrem. Někdo zjistil, že outb_p, outw_p a outl_p mají podobnou implementaci a vygeneroval ty funkce z jedné šablony makrem --- sice můžeme říct, jak to krásně faktorizoval, a jak sdílel podobný kód --- ovšem má to i podstatnou nevýhodu --- když se jako nováček neznalý Linuxového kernelu podíváš na nějaký kód volající outb_p a zeptáš se "co to volání dělá?", tak se to nedozvíš.

Pokud někdo bude do důsledků používat to metaprogramování (makra nebo eval), jak to po něm přečteš? On sám to přečte, ale jak to přečte někdo jiný?

Když chceš něco změnit v programu v C, tak to tam najdeš, snadno zjistíš jak to funguje (až na pár extrémních případů, jako výše popsaný identifikátor skládaný makrem) a změníš to. Nemusíš vůbec zkoumat, jak celý program funguje ani jakou má strukturu.

Když chceš něco změnit v programu v C++, už je to horší, už to tak snadno nepochopíš, operátory mohou být přetížené (a nevíš na co, dokud neprozkoumáš celou objektovou hierarchii), u virtuálních metod také nevíš, co se volá.

A v případě jazyků ve kterých programátor definuje vlastní lexikální strukturu, jak zjistíš, co některá část dělá? ... leda přečtením a pochopením celého toho makrosystému, co si programátor nadefinoval.

Další otázka je, jak budeš takový meta-generovaný program ověřovat. U normálních jazyků, když chceš ověřit zda o proměnných X, Y a Z platí predikát P(X,Y,Z), tak je to jednoduché --- ověříš, že P(X,Y,Z) platí na začátku, a pak si grepem najdeš všechna místa, kde se X, Y nebo Z přiřazuje, a lokálně pro každé místo ověříš, že pokud platilo P(X,Y,Z) před přiřazením, pak musí platit i po přiřazení. V momentě kdy začneš ten kód dynamicky generovat, tak už to ověříš o hodně hůř --- musíš najít všechna místa, co generují nějaký kód, zjistit, zda se náhodou nesnaží vygenerovat kód, co přiřadí do X, Y nebo Z, a pokud ano, dokázat, že všechny možné varianty kódu, co vygenerují, zachovávají predikát P.

Jiný příklad --- u normálního jazyka můžeš jednoduchou flow-control analýzou dokázat, že funkce F nesahá na proměnnou X, funkce F nebere zámek Z, atd. V momentě, kdy funkce F pouští něco, co bylo někde vygenerováno, tak to už flow-control analýzou nedokážeš.

No, je pravda, ze jsem nikdy zadny slozitejsi program v Lispu cist nemusel, tak nevim. Ale nemyslim, ze by to co pises bylo az takovy rozdil od jinych jazyku.

Predne, volani makra je uplne stejne, jako volani funkce; a vlastne ten zakladni rozdil je v tom, ze makro nevyhodnocuje argumenty. Takze podivat se, co dela dany kus kodu je stejny problem jako u funkci - staci najit definici. Vetsina maker je rozumna, takze jejich efekt je jen lokalni.

Samozrejme, jdou tam pak delat i dalsi kouzla, a i treba pomoci eval. Ale pokud se to nezneuziva, tak je to stejne komplikovane jako v C/C++.

Je to vlastne paradox, ze davas za vzor zrovna jadro, ktere pouziva dost komplikovanou (co vim) C makrologii.

Když budeš používat makra pouze k expanzi symbolů, pak to máš stejné jako C preprocesor. Vyznáš se v tom stejně jako v C programu, ale ani ti to nepřinese víc možností než C preprocesor.

Jádro Linuxu jde zkoumat takovým způsobem, že když je tam něco, co nevíš co dělá, tak si definici najdeš grepem (možná takhle projdeš několik úrovní expanzí, ale je to mechanická práce a nakonec najdeš to co chceš). Pokud ta makra pouze expandují symboly, tak to jde, když začnou dělat něco složitějšího (tvořit jména symbolů), tak už to pak takhle analyzovat nejde.

Proto se toho, co psal Biktop o návrhu lexikálních prostředků, trochu děsím. Když si 10 programátorů navrhne každý svoje lexikální prostředky a pomocí nich snadno a elegantně vyřeší svůj problém --- tak je pak otázka, jak to pak jeden po druhém bude číst?

Neni to stejne jako C preprocesor, protoze narozdil od C preprocesoru je mozne v ramci expanzi maker pouzit cely aparat Lispu, kdezto v C je preprocesor separatni a velmi slaby jazyk. A take, makra maji pri expanzi fakticky k dispozici syntakticky strom, narozdil od C preprocesoru, kde jsou to proste jen retezce.

Je pravda, ze makra muzou tvorit jmena symbolu, ale vetsina z nich to nedela.

Co se tyce te otazky, ja myslim, ze jsou to prehnane obavy. Stejne se da argumentovat i v pripade obycejnych funkci - kdyz kazdy si napise vlastni knihovnu funkci, jak to po sobe programatori budou cist? A vidis, zvladaji to docela dobre. Podle me nejvetsi problem s makry je, ze se blbe pisou a ladi; citelnost (snazsi zapis) je naopak jejich vyhoda.

"je mozne v ramci expanzi maker pouzit cely aparat Lispu"

Právě to může být i nevýhoda. V C když nevím, co něco dělá, tak si ta makra expanduju sám --- ovšem čím je ten makrosystém silnější, tím hůř se ta makra v hlavě expandují. To, že C má slabý makrojazyk je výhoda --- snáze se to čte (a IMHO by mohl být ještě slabší, operátor ## na spojování tokenů v tom dokáže nadělat bordel).

Je otázka, kdyby ti někdo ukázal velký program v Lispu, který jsi nikdy neviděl, ukázal na náhodné místo a zeptal se "co se tady dělá?", kolik toho z programu bys musel přečíst, než bys to dané místo pochopil. Ale když si nikdy větší program v Lispu nečetl (já taky ne), těžko nad tím takhle uvažovat.

V Lispu si můžeš pro kontrolu nechat makro expandovat interpretem - včetně specifikace, do jaké hloubky má při té expanzi jít. V C to vzhledem k jednoduchosti nutné obvykle není a málokdo v rámci ladění kouká na výstup preprocesoru, přestože ta možnost tam je taky. Navíc v C mají makra často povahu technické obezličky (úprava deklarace či jiné dodatečné specifikátory, platformě závislé modifikace aj.) a ne části algoritmu, takže výstup preprocesoru má obvykle gulášoidní charakter.

Já myslím, že cílem jazyků, jako je Lisp, je právě to, aby nebylo nutné psát velké programy. ;-) Navíc "problém", na který narážíš, je obecně charakteristický snad pro všechny neimperativní jazyky*, vlastně i pro objektové imperativní jazyky, jako je třeba Smalltalk, ale do jisté míry i C++ - no zkrátka pro všechny jazyky, kde jsou jiné rysy (deklarativnost, funkcionálnost, implicitnost...) posíleny na úkor imperativnosti. Jenže to je přirozená vlastnost takových jazyků, protože právě o to v nich jde, abych nemusel "disassemblovat" funkčnost programu jako překladač, ale mohl si to přečíst jako člověk, tj. pomocí názvů objektů a komentářů... ;-)

* v Lispu se samozřejmě dá programovat i imperativně, ale pro tento styl programování existují mnohem vhodnější jazyky. :-)

"Já myslím, že cílem jazyků, jako je Lisp, je právě to, aby nebylo nutné psát velké programy. ;-)"

S tím souhlasím, ale tvrdím, že u velkého programu, co píše mnoho lidí, to není podstatné kritérium. Řeknu protipříklad: máš dva ovladače, každý má N řádek kódu. Sloučíš je do jednoho obecného ovladače, který má 1,5*N řádek kódu. Sice jsi kód zmenšil, ALE před sloučením člověku pro pochopení jednoho ovladače a provedení změny stačilo přečíst N řádek kódu, po sloučení človek musí přečíct 1,5*N řádek kódu.

Není na to obecné pravidlo, kdy slučovat a kdy ne. Třeba kdyby bylo často potřeba stejnou změnu provést do obou ovladačů, tak by se sloučení vyplatilo --- vzhledem k tomu, že dopředu nevíš, jaké změny budou potřeba, tak ani nemůžeš exaktně určit, kdy je slučování kódu žádoucí nebo ne.

U velkých programů není důležité kolik to má řádek kódu (stejně je všechny nepřečteš nikdy), ale jak rychle člověk danou část programu pochopí a je schopen tam něco změnit nebo dopsat.

Já myslím, že není důvod se toho příliš děsit. Je to jak píše JS - kromě možnosti definovat funkce máš možnost definovat "metafunkce", čili makra. Přirovnal bych to asi k takovému rozdílu, že v klasických jazycích máš možnost napsat výraz a nechat počítač ať ti ho vyčíslí, zatímco v jazycích typu Lisp máš možnost napsat rovnici a nechat počítač ať ti ji vyřeší a výsledné řešení případně vyčíslí. Jistě, nebudeme si nic nalhávat - je to náročnější na představivost, ale řekl bych v tom pozitivním smyslu - tak jako ve fyzice (středoškolské) většina lidí asi pochopí, jak vyřešit rovnici a najít tak výraz, ovšem podstatně méně lidí už dovede na základě nějakého problému sestavit tu rovnici, jejímž vyřešením dojde k výrazu, po jehož vyčíslení obdrží kýžený výsledek (u VŠ fyziky je to spíš naopak, že - rovnici dám dokupy docela snadno, ale neumím s ní pohnout :-). Proto říkám, že k efektivnímu použití Lispu je třeba překopat myšlení - uvědomit si ty metavlastnosti jazyka a dokázat je vhodně využít. Takže když jsem psal o tom návrhu lexikálních prostředků - může to fungovat např. tak (jen jednoduchý příklad, vždycky když člověk potřebuje nějaký zajímavý příklad, tak ho napotvoru nic nenapadne :-) , že v C máš k disposici 1D a 2D pole; nemaje lexikálních prostředků k vyšším rozměrům patrně uděláš 1D pole a jeho indexaci budeš řešit "ručně" a úplně jinak než ty dva speciální případy (pomocí ne úplně přímočaré funkce nebo pomocí funkce vygenerované makrem - ale dost krkolomně a budeš omezen na znalost dimenze v době preprocesingu) - tohle mi nepřipadá zrovna moc přehledné a "ortogonální"; v Lispu si napíšeš velice jednoduché a přímočaré makro, které ti na požádání vygeneruje N-rozměrnou indexovací funkci, kde N je argumentem toho makra - takže ti tu potřebnou funkci vygeneruje třeba na základě dosavadních výsledků apod. I když tohle je primitivnost která ti je jasná, zdůrazňuji, že tenhle mechanismus máš k disposici v run-timu a jazykové prostředky, jež při tom můžeš využít, nejsou nijak omezené, jak už psal JS - obojí v protikladu s makroprocesorem v C: tím makrem můžeš za běhu (!) vygenerovat třeba (nebo spíš obvykle ;-) lambda-funkci, kterou předáš jako argument k dalšímu upotřebení, nebo dokonce jiné makro. V tomhle já právě vidím tu úžasnou tvárnost toho jazyka.
Jasně - na první pohled je asi zřejmé, že síla tohoto mechanismu bude nejvíc vidět u problémů, kde složitost závisí na vstupních parametrech - typicky problémy vedoucí k N vnořeným cyklům, k N-rozměrné rekursi atp., kde N není jen parametrem, ale vystupuje v těch algoritmech jako normální argument. Ale není nezbytně nutné řešit s tím jen tyhle "akademické" problémy - zatímco v C budeš řešit, jakou vhodnou datovou strukturu použít jako kompromis mezi optimálním popisem informace a složitostí a přehledností operací, jež s ní chceš provádět, protože při realisaci těch operací jsi v podstatě omezen jen na funkce, u nichž jsi poměrně značně svázán pokud jde o nutnost znalosti povahy těch dat v době kompilace, v Lispu si můžeš velice výrazně pomoci makry. V C máš k realisaci dynamické mnohotvárnosti dat programu k disposici v podstatě jen ukazatele jakožto nástroj funkcí - což je ze své podstaty pasivní objekt (a taky dost nebezpečný). V Lispu na to můžeš použít aktivní objekty - funkce+makra (o nic méně bezpečná, nicméně řádově silnější než kombinace funkce+pointery). Jde jen o to si na tenhle kvalitativně dost odlišný přístup k návrhu postupně zvyknout, uvědomit si, že už nejsem vázaný na poměrně rigidní datové struktury, ale že si cokoli můžu kdykoli velice plasticky přetransformovat, reinterpretovat podle potřeby.

Zkrátka abych to shrnul - jestliže v klasických jazycích jsi omezený na programování v 1D, 2D (nebo 2,5D :-), v Lispu můžeš dělat v N - jsi omezen jen svou hlavou, do jaké dimenze to zvládne. :-) Dostat se od nás do Austrálie je docela zdlouhavé - pokud jsi omezen jen na povrch Země. Když můžeš skrz, je to jednoduché a přímočaré, pokud si dokážeš představit, že je Země kulatá. A zrovna tak je to s přehledností dobrých programů v Lispu - nejsou write-only, ani nejsou složité, naopak - obvykle jsou mnohem jednodušší než jejich ekvivalenty v jiných jazycích. Ale chce to sžít se s přítomností maker a dokázat vystoupit z té plochy a uvědomit si, že teď už můžeš jít i "skrz".

Představ si, že někdo napíše makro pro přístup do pole o libovolném počtu rozměrů, pak napíše další makro, které to obecné pole bude procházet a na každý prvek aplikovat nějakou funkci, pak další makro, které to obecné pole bude zpracovávat medou rozděl a panuj a tak dál.

S použitím těch maker můžeme na jeden řádek napsat třídění, na jeden řádek napsat nalezení nejmenšího prvku a spoustu dalších algoritmů.

A teď ten problém: Většina polí ve velkém programu je jednorozměrná. Napsat nalezení nejmenšího prvku na jednorozměrném poli můžeme v C na 4 řádky:

int i;
int minimum = MAXINT;
for (i = 0; i < sizeof(pole) / sizeof(*pole); i++)
        if (pole[i] < minimum) minimum = pole[i];

Čili v C napíšeme 4 řádky a přečteme 4 řádky (stačí ti přečíst jen ty 4 řádky, zbytek programu tě vůbec nemusí zajímat), v Lispu napíšeme 1 řádek a přečteme několik desítek řádků.

Mně to vhodné pro vývoj aplikací vůbec nepřijde. Takový makrojazyk může být vhodný pro řešení matematických problémů, ale v běžných programech se 2-rozměrné pole vyskytuje zřídka a vícerozměrné skoro nikdy.

Mně to přijde tak, že čím víc má některý jazyk syntaktických prostředků, tím snáze se v něm programuje a tím hůře se v něm čte. Protože práce na aplikačních program je z větší části čtení kódu (nikoli psaní), tak použít jazyk, který si kdo chce může jak chce upravit, nemusí být nejlepší.

Nebo proč jinak myslíš, že se Lisp nepoužívá, a používá se místo něho C, C++, Java, Python? Existuje vlastně nějaký velký uživatelský program v Lispu?

No, teorie je to dobra. Nicmene je otazka, zda Perl/Python/Ru­by/PHP jsou vhodne na psani aplikaci - take neni trivialni pochopit dane misto a zmenit, diky zejmena duck typum a dalsim featuram (nejvic u Ruby a Perlu).

Ja myslim, ze duvod, proc lide na psani aplikaci pouzivaji C,C++, Javu a Python souvisi s revoluci mikropocitacu (kdy se temer vse kolem pocitacu vynalezalo od piky). Lisp mel GC a byl na male pocitace pomaly bez kompilace, proto se lide naucili pouzivat C a C++, na ktere v podstate prechazeli z BASICu a Pascalu (a ze stejneho duvodu ignorovali Lisp a Smalltalk, kde druhy by byl jasny kandidat).

No a to se historicky pak uz preneslo dal. Podle me pouzivani toho ktereho jazyka souvisi s vychozi platformou a zkratka historii, mene s tim, jak dobre se v nem programuje. (Ostatne, dalsi vec, ktera Lisp pohrbila, bylo mnoho konkurujicich uzavrenych implementaci, kazda s jinou knihovnou. Mam teorii, ze slozitost implementace jazyka - nebo jineho SW systemu - je pro nej evolucni vyhodou, a usnadnuje jeho preziti - viz tez Forth.)

Nechci obhajovat PHP jako vhodny jazyk na tvorbu aplikaci (vlastne bez nejakeho frameworku ktery prekryje vsechny ty problemy cisteho PHP bych to naprosto nedoporucoval, a i s frameworkem je to porad strasne pomale), ale zdrojaky cizich aplikaci se v nem ctou uplne bez problemu, neni problem se tam zorientovat za par vterin a neco predelat.

Pokud je to dokonce delane TDD metodikou, tak je mozne delat velke upravy na cizim kodu hned prvni den co ho clovek vidi (alespon moje zkusenost overena z praxe).

Ad GC ... porad nechapu komu vlastne chybi GC a k cemu je to dobry. Nejak jsem nikdy zadne vazne problemy s manazovanim pameti nemel. Chapu ze kdyz clovek nepremysli co pise, tak nadela v C/C++ paseku a pak ma pocit ze je to slozite, ale tak ono by bylo nejdriv dobre psat kod ktery dava smysl, az pak se bavit o tom jestli je rucny memory management slozity. Vzhledem k tomu ze vetsina realnych problemu je data-oriented (neco tam vlozite a chcete neco dostat ven), tak z dobre analyzy problemu vetsinou automaticky vypadne i zpusob nakladani s pameti, protoze ty data se nemuzou jen tak ztratit nebo rozkopirovat. A C/C++ poskytuje mocny nastroj na docasnou alokaci pameti v tom spravnem okamziku uplne *trivialnim* zpusobem (stack). Pristup na heap obvykle obslouzi wrapper ve forme kontejneru. A je to, problemy jsou pryc.

Ja myslim ze duvod proc se pouziva C/C++, Java a Python (dle mnozstvi nasazenych aplikaci sem urcite patri i PHP, ackoli mira amaterismu dane mnoziny prevysuje slusnou mez) je v tom, ze vetsina programatoru je v nich proste produktivnejsi nez v jinych jazycich. Vetsina programatoru jaksi nejsou matematicti geniove, spis naopak, a casem se to jiz jen zhorsuje, protoze nove nastroje jsou porad vic a vic pristupnejsi i tem mene genialnim lidem. (co bych z pohledu lidstva bral jako plus, ale at prosim funguje nejake kastovani a ti lepsi nemusi vyzirat problemy po tech horsich, pak s tim budu umet zit uplne v klidu)

Já bych to bral naopak jako velké minus - lidi, kteří mají schopnosti leda na kopání výkopů nebo obsluhu dopravníku hnoje na statku, se motají do něčeho, nač nemají a jejich hlavu jim nenahradí ani sebesofistiko­vanější nástroj - se všemi důsledky, jež z toho plynou (pro lidstvo :-).

No, ale zase takoví lidé mají nižší procento výskytu poruchy osobnosti a jsou schopni styku se ženou. Viz zde: http://www.jikos.cz/~mikulas/komix/FREESOFT.GIF

:-D
Ty sis dělal nějaký statistický průzkum? :-) Znám i pár jakože-programátorů, kteří mají asi taky poruchy a nejsou schopni styku se ženou (proti nim si můžeš fandit - představ si, že bys byl looser i v programování :-), znám dokonce i traktoristu, který není schopen styku se ženou kvůli nějaké psychické poruše, stejně jako znám dost dobré matematiky, fyziky, programátory, kteří se ženami styk mají. :-) Krom toho - nevidím nic sexy na tom, že někdo umí splácat jakousi patlaninu v ASP.NET - to dnes umí každý druhý. Ale když sedím s kolegy - BFprogramátory a samicemi, jež si přivedli, třeba v hospodě, pozoruji zvýšený zájem, když zeptavše se mě na mou práci obdrží od těch kolegů odpověď "na to se ho radši neptej, to nechápeme ani my". :-)

Někteří psychologové tvrdí, že schizoidní porucha koreluje s vysokou inteligencí.

Kdybych byl blbej na programování a ještě k tomu psychopat, tak bych mohl sociální interakci rozvíjet jinak, třeba takhle: http://comix.spaceport.cz/index.php?id=12975

"nevidím nic sexy na tom, že někdo umí splácat jakousi patlaninu v ASP.NET" --- no ta ženská to nevidí taky, protože neví, co je to ASP.NET, je jí prakticky jedno, jestli řekneš, že jsi napsal webovou stránku v ASP.NET nebo že jsi vyřešil nějaký problém kernelu. Ba ne, tu webovou stránku ocení víc než kernel, protože na tu se aspoň umí podívat.

Já bych hlavně ty poruchy nebral zas tak smrtelně vážně. Psychická porucha je odchylkou od normálního stavu mysli. Vysoká inteligence je nepochybně taky odchylkou od normálu, takže mi ta korelace nepřipadá zase tak podivná. Je to určitě příjemnější odchylka než podprůměrně nízká inteligence a s ní korelované poruchy. :-) Narozdíl od těchto něšťastníků ti tvoje mysl dovoluje analyzovat chování druhých a syntetisovat na základě těchto analýz postupy vhodné pro tvoji interakci s okolím. :-)

To bych neřekl. Ženské bude jedno, že neví co to je. K tomu, abys v jejích očích poskočil na žebříčku atraktivity jí stačí vědět, že je to něco, v čem se vyznáš ty a pár dalších a jinak nikdo a všichni to o tobě vědí. :-)

"Ženské bude jedno, že neví co to je. K tomu, abys v jejích očích poskočil na žebříčku atraktivity ..." --- takový ženy sice jsou, že kdybych se před nimi přímo nebo nepřímo vychloubal, tak by se vzrušily. Ale podobná "hra" zase vůbec nevzrušuje mě. Nedokázal bych si vážit ženy, která se nechá takhle jednoduše manipulovat.

"ti tvoje mysl dovoluje analyzovat chování druhých a syntetisovat na základě těchto analýz postupy vhodné pro tvoji interakci s okolím." --- jenže inteligence mi neumožňuje syntetizovat vhodné emoce. Pohled v očích, výraz tváře, tón hlasu --- to se nedá emulovat.

Nic o vychloubání jsem neříkal.

No jo, ale potom není co řešit. To je jako by všichni kolem tebe pravidelně chodili na cigaretu a ty jsi měl deprese z toho, že si tu cigaretu nemůžeš dát taky, protože ti to chuťově nic neříká. Tak buď ti "styk se ženami" chybí a tedy to na tebe emočně nějak působí a když vidíš nějakou atraktivní holku tak nějaké emoce při tom pociťuješ, nebo žádné emoce nemáš, ale pak je mi divné, že z toho můžeš mít špatné emoce. :-)

"To je jako by všichni kolem tebe pravidelně chodili na cigaretu a ty jsi měl deprese z toho, že si tu cigaretu nemůžeš dát taky, protože ti to chuťově nic neříká."

S tím souhlasím. To jsi přirovnal velmi přesně. Ale nevidím v tom žádný rozpor.

Kdybys měl společnost, která "chození na cigaretu" považuje za sociální rituál, kterým utužuje vztahy mezi jednotlivými členy, a do takové společnosti se dostane člověk, kterému cigareta nechutná, tak je ten člověk v té společnosti úplně vyřízený. Nemůže nic. Nemůže mít kamarády (protože by to znamenalo "jít na cigaretu"), nemůže mít partnerku (protože by s ním chtěla chodit na cigaretu), nerozumí se spolužáky ani kolegy (protože oni si přece utužují kolektiv u cigarety) atd. Nevím, nad čím se divíš --- deprese je logické vyústění situace.

"Tak buď ti 'styk se ženami' chybí a tedy to na tebe emočně nějak působí a když vidíš nějakou atraktivní holku tak nějaké emoce při tom pociťuješ"

Občas (zřídka) takové emoce k ženě pociťuju. Někdy jsem si i představoval, jak krásné by to bylo ženu milovat. Ale jde právě o to, že cítit samotné emoce nestačí, při navázání vztahu i během vztahu je potřeba provádět spoustu sociálních rituálů, a ty mi nic neříkají.

Problém ani není v tom, že bych se ty sociální rituály nemohl naučit. Problém je v tom, že když můj mozek něco vyhodnotí jako rituál, tak to pro mě přestane být zajímavé a nedokážu se tím nijak nadchnout.

Já s nimi na tu cigaretu také nejdu, a ještě jim klidně vynadám že jsou banda smradlavých feťáků ;-)

k tomu GC

kdyz v C/C++ premyslite nad algoritmem, tak nutne musite prave mem mgmt brat v uvahu a to vas nutne omezuje, napr. ve chvili, kdy chcete z ruznych duvodu pouzit copy on write, tak si neusetrite netrivialni udrzovani infa o tom, co je kopie vase a co z venku atd.

new/delete je obecne pomalejsi nez Sun JVM GC (nebo jak se to dnes nazyva), nevim jak u jinych platforem

(de)alokace je oblast, kde se delaji casto chyby, navic to jde automatizovat, tak proc tim zatezovat cloveka, kdyz to vyresi stroj vetsinou lepe

Ale to je totéž, co tu už naznačoval JS - jak se tebou nadnesený problém liší např. od použití knihovních funkcí nebo knihoven tříd? Přece při programování obvykle nestuduješ, jak fungují jednotlivé funkce v knihovnách, ostatně často to ani není možné, když k nim nemáš zdrojáky. Ty jsi asi spíš systémový programátor, co? ;-) Protože tyhle argumenty jsou blízké lidem, co dělají blízko železu - ovladače, jádra OS atp. a jsou zvyklí na to, že na téhle úrovni softwaru je poměrně obtížné programovat čistě a stejně z toho nakonec vyleze větší či menší programový chrchel, takže je nutné přesně vědět nejen co dělají, ale i jak jednotlivé komponenty toho chrchlu fungují. Jinak bys mohl zpochybnit celé objektové programování a vlastně i strukturované programování - místo abys napsal něco jako GOSUB xxx, tak napíšeš jméno nějaké rutiny, ale stejně si musíš přečíst, co ta rutina dělá. Přece všechny ty heterogenní datové struktury, uživatelsky definované funkce a později třídy a objetky byly vymyšleny hlavně kvůli tomu, abys mohl uzamknout jednotlivé funkční celky, mohl je ladit pokud možno odděleně a nezávisle a pak k nim mohl přistupovat jako k černým škatulkám, kdy nutnost znalosti jejich vnitřku je naopak nežádoucí, protože navenek se mají z hlediska programátora projevovat jen svým rozhraním.

S těmi syntaktickými prostředky - to bych váhal. Když si vezmeš třeba Adu nebo i obyčejný Pascal, tak ty mají těch syntaktických prostředků poměrně dost, ale přesto se v nich dá číst velice dobře i poměrně špatně napsaný program. Souhlasím, že u Lispu nebo u Forthu je to vyloučeno - tam špatný program vypadá fakt jak mimozemská šifra. Ale dobrý program se tam čte jak pohádka pro děti. Kdybych vzal Adu a proti ní postavil Lisp, řekl bych, že autoři Ady předpokládají, že programátor je blbec, může zkopat co se dá a pokud se nedokáže vyžvejknout jasně, tak to je příznakem, že neví, co chce a je třeba ho okamžitě zabrzdit v jeho počínání. U Lispu to je přesně obráceně - autoři předpokládali, že programátor obvykle ví co dělá a jak toho chce docílit, proto má možnosti otevřené do té míry, že si k těmto účelům může neomezeně tvořit syntaktické prostředky. Syntaxe samotného Lispu je zcela primitivní. Syntaxi Ady vymýšleli zkušené otevřené hlavy, jenže programy tvoří obvykle hlavy mnohem méně zkušené a bystré, čehož si ty první hlavy byly velice dobře vědomé.
Riziko jazyků typu Lisp je právě v tom, že i nezkušený člověk s ne příliš vyvinutým abstraktním a analytickým myšlením má možnost dělat věci, k nimž mají u jiných jazyků výsadu pouze jejich tvůrci - zasahovat do syntaxe. A řekl bych, že i to je důvodem, proč se jazyky jako Lisp nebo Forth nepoužívají masově - protože málokdo má k jejich efektivnímu použití vlohy. Že většina lidí v životě neřeší diferenciální rovnice nebo při nakupování neoperuje se simplexovou metodou není problém těch rovnic - to je problém těch lidí, že na to nemají hlavu.
C se jednoznačně rozšířilo s Unixem a s MS-DOSem. A nejsem si jist, že to bylo zrovna nejšťastnější řízení osudu. Když v něm zkušený člověk píše jádro OS, je to perfektní jazyk. Ale když v něm průměrně schopný programátor dělá aplikaci... Ovšem i můj pohled na C jakožto na ideální systémový jazyk byl otřesen, když jsem studoval Oberon, což je IMHO důkaz, že i OS se dá elegantně napsat v hodně restriktivním a přitom docela jednoduchém jazyku a že to má velice pozitivní vliv na návrh jeho datových struktur a srozumitelnost jeho zdrojáků.

Když použiješ knihovní funkci na pole, jiný programátor s velkou pravděpodobností ví, jak to funguje. Když použiješ vlastní makro biktopovo-n-rozmerne-pole, tak nikdo neví, jak to funguje.

Jak by se to metaprogramování mělo řešit na velkém projektu?

* nechat si každého programátora napsat vlastní makro na pole --- pak jeden nepřečte kód druhého, ani si to pole nebudou schopni efektivně předat.

* seskupit programátory a nechat je navrhovat makro způsobem "a já bych tam ještě přidal proměnný počet rozměrů" ... "a já bych tam ještě přidal kompresi nepoužitých prvků" ... "a já bych tam ještě přidal efektivní přidávání prvků doprostřed" ... "a já bych tam ještě přidal bla bla bla" --- pak ti z toho vznikne neuzvěřitelný bastl.

* nebo vedoucí projektu to makro na pole navrhne a pak direktivně řekne "použije se toto makro na pole, jiná makra na pole jsou zakázána, chce-li někdo funkcionalitu, která tam není, má smůlu, musí ten svůj problém jinak řešit". Asi nejlepší řešení. Jenže místo toho rovnou můžeš říct "použije se C++ STL, vlastní implementace datových struktur jsou zakázané", vyjde to nastejno, navíc ušetříš čas návrhu a implementace a učení-se těch vlastních maker.

"Přece při programování obvykle nestuduješ, jak fungují jednotlivé funkce v knihovnách" --- knihovny nestuduji, ale studuji, jak fungují jednotlivé funkce, které napsali jiní programátoři na témže programu. To jinak ani nejde. Program (ani aplikační) nenapíšeš způsobem "uděláme specifikaci rozhraní mezi moduly, pak jednu skupinu necháme psát implementaci toho rozhraní, druhou skupinu necháme to rozhraní použít, a jedna skupina se nebude muset dívat na kód druhé". Když to rozhraní navrhneš, tak to navrhneš s velkou pravděpodobnostní blbě, že to půjde těžko implementovat nebo to bude nepoužitelné. Když se zjistí, že je to těžko implementovatelné, musí se to rozhraní změnit. Když se zjistí, že je to nepoužitelné, musí se to rozhraní taky změnit.

Ten návrh rozhraní mezi částmi programu je spíše iterativní cyklus "pokusíme se to specifikovat, pokusíme se to implementovat, opravíme specifikaci, aby se to lépe implementovalo, pokusíme se to použít, opravíme specifikaci, aby to bylo použitelné, změníme implementaci podle specifikace, pokusíme se to použít víc, zjistíme, že je tam ještě potřeba tohle, zjistíme, že tohle ve specifikaci jsme nikde nepoužili, tak to odstraníme, atd." Když tenhle cyklus dobře opakuješ, vznikne ti z toho solidní použitelné rozhraní. Když ten cyklus neděláš, tak z toho vznikne "návrh od komise".

Přiznám se ti, že já na žádných velkých projektech, kde se motá halda programátorů, nedělám. Nějak mě unavovalo hádat se s hlavním analytikem, který netuší, co to ta analýza vlastně je a nechávat si posílat zdrojáky kolegů, kteří umějí programovat asi jako má matka po 14denním zaškolení...
Ovšem stejně mi pořád nedochází, kde vidíš ty hlavní problémy - přece dostanu-li za úkol vytvořit modul, který bude realisovat nějakou databázi a bude reagovat na dotazy vyšší vrstvy, nikoho nemusí zajímat, jaká makra si tam vytvořím k "fyzické" realisaci těch dotazů; to bude sloužit interně jenom tomu mému modulu - např. makra generující nějaké výběrové funkce, indexové funkce aj. A organisačně se takový projekt v Lispu nijak výrazně lišit nebude od organisace projektu třeba ve Fortranu nebo v čemkoli jiném - proč by měl?

"nikoho nemusí zajímat, jaká makra si tam vytvořím k 'fyzické' realisaci těch dotazů; to bude sloužit interně jenom tomu mému modulu"

Bude to lidi zajímat:

- Někdo ten tvůj modul použije, nebude mu to fungovat. Musí zjistit, zda je chyba u tebe nebo u něho (a přečíst i tvůj kód).

- Program bude pomalý, musí se zjistit proč. Opět bude někdo číst tvůj kód.

- Ta specifikace rozhraní bude neúplná, někdo tam bude potřebovat něco dopsat.

Zde bohužel, čím kreativnější programátorské techniky použiješ, tím se to bude neznalému člověku hůř číst. Třeba složitost jde u takových jednoduchých programů zjistit banálně podle vnořených cyklů. Ale když si ty vnořené cykly budeš generovat makry, co si sám napíšeš, tak už to tak snadno zjistit nepůjde (člověk bude muset prvně pochopit ideu těch maker než se bude moct ptát "jakou to má složitost?").

To jo, ať si to přečte, ale nemusí je používat. A já si fakt nemyslím, že by to bylo tak nepochopitelné. Když jsem měl za úkol upravit cosi v programu na rozpoznávání drah částic napsaném ve FORTRANU 66 bez jediného řádku komentáře, byl to mnohem horší zážitek než probírat se lispovskými makry. Promiň, ale mně to připadá, jako bys tvrdil, že algebraické výrazy jsou nepřehledné, protože tam místo čísel vystupují písmena, když to trochu zjednoduším. Nebo že matematická tvrzení jsou nepřehledná, protože místo konkrétních funkcí, konkrétních objektů hovoří jen o nějakých blíže nespecifikovaných objektech, splňujících vlastnosti uvedené v předpokladech. Pro spoustu lidí to opravdu je nad jejich síly, ale pro ty, pro něž to nad jejich síly není, je to přece obrovské usnadnění a zbraň, jež jim dovoluje jít mnohem dál nebo aspoň s mnohem menší námahou, než ti omezenější. Je to sice zas takový trochu blbý příměr, ale absolvent gymnázia (dnes už asi spíš prváku na VŠ) bude schopen spočítat integrál přes 2pí z sin na 4. krát cosinus na 5. Docela se u toho zapotí využívaje jen ta nejstupidnější pravidla o integrování. Ale člověk, který má trošku abstraktní nadhled, to spočítá z hlavy během chviličky pomocí Beta-funkce. Když si to po něm přečteš, nebude ti to připadat nikterak překvapivé a nepochopitelné - výpočet na půl řádku. Pokud bude výsledek nesprávný, snadno najdeš chybu - třeba vynechal jeden Gamma-faktor při vyčíslování té Beta-fce. Pro toho, co zná jen per partes, to bude postup jak ze star treku a absolutně nebude chápat, co to tam ten dotyčný vlastně dělal. Ale když budeš muset ty hledat chybu v jeho myšlenkově jednoduchém, leč pracném postupu, budeš muset projít půl A4ky výpočtů, kdy v každém kroku mohl udělat nějakou botu. Přece postup využívající speciální funkce není nepřehlednější nebo dokonce horší než ten primitivní jen kvůli tomu, že spousta lidí si nedokáže dát dvě a dvě dohromady a ulehčit si práci...
Já si naopak myslím (a nejsem sám a zdaleka ne první, koho to napadlo), že množství chyb je korelováno s množstvím napsaného kódu. Takže minimalisací nutnosti psát kód taky minimalisuji pravděpodobnost zanesení chyby. Pokud dokážu postup výpočtu a strukturu dat vzájemně dekomponovat tak, že celý program budu moci poskládat s maximálním využitím jednoduchých kroků automaticky vygenerovaných jinými nekomplikovanými algoritmy, tak to přece je zpřehlednění, zjednodušení a snížení rizika chyby - mám jednoduše strukturovaná data, s nimiž budu provádět četné jednoduché operace (kdybych je měl psát ručně, tak bych se zbláznil nebo by to dokonce bylo nemožné, proto u "klasického" návrhu bych musel postupovat úplně odlišně, data jinak strukturovat, k jejich zpracování použít jiné metody), jež budou ad hoc generovány pomocí jednoduchých receptů.
Podle mě to prostě není taková divočina, jakou v tom vidíš ty. To je podobné, jako by ses děsil, že matematická logika připouští vedle obyčejných výroků i predikáty. Většina normálních lidí má problémy i s těmi obyčejnými výroky, ale těm, kterým ty predikáty problémy nečiní, schopnost pracovat s nimi výrazně ulehčuje práci. Zarecituj obyčejnému smrtelníkovi klasickou definici limity číselné posloupnosti - u třetího kvantifikátoru to přestane brát. Máme snad kvůli lidem jako on rezignovat na počítání s limitami nebo se domnívat, že je to až příliš komplikované?

Mně přijde, že člověk by měl používat nejjednodušší prostředky, které vyřeší daný problém.

Ad ty úvahy o složitosti matematiky:
Představ si třeba, kdybys popsal růst dluhu diferenciální rovnicí. To můžeš, je to popsáno matematicky elegantně, ale má to problém --- vymahačská firma tomu nerozumí (proč by měla zaměstnávat matematika?), dlužník tomu asi taky nebude rozumnět ... a kdybys to chtěl vymáhat soudně, tak tomu soudce nebude rozumět též a ty si budeš muset zacvakat soudního znalce, který tam tu diferenciální rovnici vyřeší a zjistí, kolik teda má dlužník platit. Proto se prostě dluh neřeší diferenciální rovnicí, ale diskrétními vzorečky, které to den po dnu napočítávají. Řešení je to neelegantní, tupé, ale splní to účel a průměrný účetní si do toho vzorečku dokáže dosadit a spočítat to.

Čímž nemyslím, že diferenciální rovnice jsou blbost. Jen je to na daný problém dluhu jako "kanón na vrabce". Myslím, že jde-li problém řešit bez diferenciálních rovnic, tak ho řešit bez nich. Stejně tak, když jde program napsat bez metaprogramování, tak ho psát bez něj.

"Pokud dokážu postup výpočtu a strukturu dat vzájemně dekomponovat tak, že celý program budu moci poskládat s maximálním využitím jednoduchých kroků automaticky vygenerovaných jinými nekomplikovanými algoritmy, tak to přece je zpřehlednění, zjednodušení a snížení rizika chyby" --- otázka je, kde takový správně dekomponovaný veliký program v Lispu je? Já znám v Lispu jen toho psychiatra v Emacsu, se kterým si občas povídám o své psychické poruše. Když něco tvrdíš, tak to ukaž.

A co kdybys to zkusil ty, naprogramovat neco netrivialniho v Common Lispu? Vzdyt - zivot je kratky, na zeny stejne kasles, tak v cem je problem?

Treba ti ten jazyk zacne vyhovovat. Je dost velmi chytrych lidi, kterym vyhovuje, coz uz samo o sobe je duvod to zkusit. Nekterym mozna ne, ale i ti uznavaji, ze je "life-changing experience" (jako Eric Raymond).

Ja jsem to tak udelal, a kdyby pro me stale nebylo v Pythonu par veci snazsich (coz je spis otazka moji Lispove nezkusenosti, zatim) a nemel lepsi standardni knihovnu, tak uz na svoje programovani pouzivam Lisp temer exkluzivne.

(Jinak Emacs Lisp neni nic moc, co jsem slysel, protoze nema lexikalni promenne.)

Určitě jsi už slyšel nějakou tu lidovou hádanku typu "Otec měl tři syny. Po jeho smrti si měli dědictví rozdělit takto: první měl dostat o 2/3 víc než druhý, jenž měl dostat o deset liber méně a 1/5 více než třetí, atd..." Nebo "až bude matce 2x tolik co jejímu staršímu synovi, bude její dceři o 5 let méně než..." BFU to řeší víceméně pokus-omylem, proto je to pro ně tak náročné. Nevím jak ty, ale já si napíšu (nebo představím) rovnice pro ty jednotlivé persóny a ty prostě vyřeším. Podle tebe jdu s kanónem na vrabce jen kvůli tomu, že většina populace můj postup nepochopí, přestože na něm nic nepochopitelného není - naopak, je přímočarý a deterministický, narozdíl od toho jejich?
Jít s kanónem na vrabce - to je počítat obsah trojúhelníku pomocí integrálu, když na to mám jednoduchý vzoreček, nebo třídit nějaké pole pomocí quicksortu, když těch prvků tam je pár desítek a potřebuju je seřadit jednou za uherský rok. Ale z pohledu lispaře takovým kanónem může být třeba snaha napsat nějakou komplikovanou funkci pro generování kódu v nějakém překladači, beroucí v úvahu stopadesát různých možností, když se dá napsat makro, jež mi ty odpovídající konkrétní funkce vygeneruje.

Záleží, co to je podle tebe velký projekt... Vedle emacs třeba
http://www.paulgraham.com/carl.html
http://www.franz.com/success/customer_apps/bioinformatics/mdl_story.lhtml
http://flightcaster.com

A v historii by se toho našlo víc - na Lisp Machines toho bylo dost :-)

Je neúčelné učit se řešit N rovnic o N neznámých kvůli kvízům. Pro BFU je skutečně časově méně náročné, když těch pár kvízů, co v životě uvidí, bude hádat, než když se bude několik měsíců učit matematický aparát. Ty rovnice nebyly dělány na kvízy, to, že se jimi dají řešit kvízy, je side-efekt.

Stejně tak považuju za neúčelné používat abstrakci na pole s proměnným počtem dimenzí, když v běžném aplikačním programu jsou skoro všechna pole max. dvourozměrná. Abstrakce na nesprávném místě škodí.

potvrzuji ten forth ;)

... Navic neprotireci si autor nahodou kdyz na jedne strane chce unicode znaky a na druhe strane se mu nelibi C-ckove operatory "|" a "&" ? ...

Autorovi se nelíbí, že existují operátory "|" a "||", respektive "&" a "&&".

ta ceresnicka na konci prispevku nema chybu - uplne vystizne ..
co sa tyka reakcie tak suhlas - syntax je ten najmensi problem v programovani ..

zaujimave je, ze autor je `fanda' pascal-u; podla mojho nazoru snad horsia syntax ako mal pascal neexistuje .. "derie oci"

Běžím shánět hořlaviny a zápalky, protože Vás jako zanícený pascalista musím upálit

videl, ale nenaprogramoval som v nom nic, takze nemozem porovnat ..

inak som die-hard fan of C, C-syntax je mi k srdcu najblizsia

Článek se místy čte, jako by šlo o výstup z automatického translátoru.
Ať už je to snaha o specifický autorský styl, nebo prostě jen autorova "idiomatická zvláštnost", tak to příště prosím neopakujte.

Stačila by zprávička s odkazem.

Zahajujem vyvoj programovacieho jazyka "klingol", vstetci zaujemci si prosim kupte tuto klavesnicu.
http://dvice.com/archives/2009/01/klingon_keyboar.php

Dakujem

I tuhle klávesnici zprznili tlačítky se satanovými obrazci (logo Windows), to nemají Klingoni nějaký inteligentnější OS?

Správný klingonský válečník se svým OSem svádí každodenní bitvy. Klingoni měli původně jiný systém, ale při pohledu na Windows zajásali, protože se k používání hodily ještě méně.

Máš zpoždění jenom asi 46 let... :-)

http://en.wikipedia.org/wiki/APL_(programming_lan­guage)

A jak se ty Unicode znaky (mimochodem nepadl jediný příklad, který tak znak by se měl použít a pro co) budou rychle psát? To jako budu pro psaní v daném jazyce potřebovat speciální klávesovou mapu nebo speciální vývojové prostředí, které to za mne doplní? To tedy práci opravdu velmi zjednoduší a urychlí...

Budete vedle normalni klavesnice mit jeste druhou o plose dva metry ctverecni, abyste mohl psat operatory v cinstine, hebrejstine, rectine, klinovem a provazkovem pismu a vikingskych runach.

Možná vám to přijde k smíchu, ale: http://scalaz.googlecode.com/svn/continuous/2009-12-22+5279.134594s/scaladoc/scalaz/Identity.html

To je snadne, budou specialni klavesnice pro programatory. Uz dnes se bezne prodavaji specialni klavesnice do kancelare, pro multimedia a pro hrace. Budou i klavesnice navrzene pro programatory... ;-)

Spíše na ní bude více tlačítek typu "CTRL", které po stisku budou měnit význam stávajících kláves. Tedy kupříkladu kombinace "XCTRL + F" vloží text "for". Co která klávesa bude dělat si buď budeme muset pamatovat, nebo napsat na klávesnici (sir Sinclair to zvládl) nebo se inspirujeme u hráčů a budeme používat klávesnici, kde je v některých klávesách malý display, který bude zobrazovat co právě ta klávesa znamená (v závislosti na těch již stisknutých). Mimochodem, já už tyhle "rozšířené" klávesy mám. Na mém notebooku je modrá klávesa "Fn", která s řadou jiných kláves funguje (například Fn + p je znak *). Já jsem si pak dodefinoval další kombinace a mám na ně pověšená makra, která píšou různé delší texty. Výborná věc, akorát že si musím ty klávesy pamatovat a na cizím počítači mám problém.

To už by tu bylo...
http://gadgets.zive.cz/klavesnicove-bici-od-googlu/a-20813/default.aspx

Podle mě je největší omezení programátorů to, že musejí datlovat jednotlivá písmenka a jiné znaky. IMO je program v textové podobě dost nepřirozený a dost omezený. Vymyslet nějaký koncept je jednoduché, ale zapsat to v nějakém jazyce a ještě drátovat dohromady, přidávat knihovny, pak debugovat atd. je dost náročné. Stále čekám na něco moderního, stejně tak jako na nahrazení v dnešní době prehistorického vstupního zařízení jakým je klávesnice se stovkou tlačítek. No a s tím taky souvisí ASCII, pro které je ta klávesnice dělaná. Psaní dostatečně rozmanitých Unicode znaků již vyžaduje krkolomné chvaty :) Snad se nedotknu profi programátorů, ale připadá mi, že lidi jsou už nějakou dobu brzdou vývoje SW a výpočetní techniky vůbec, prostě nestačí držet krok se stále rostoucím, exponenciálním tempem rozvoje. Ještě aby ne, když člověk je od přírody schopen uvažovat a učit se pouze lineárně.

http://en.wikipedia.org/wiki/Visual_programming

Nejvetsi peklo ... misto toho, abys resil co ma tvuj program delat, stravis klidne i hodinu tim ze se snazis prijit na to jak to naklikat tak, aby tomu to dementni vyvojove prostredi rozumelo

To je prece obecny problem zvladnuti syntaxe daneho jazyka, ktery bude mit kazdy, kdo prechazi na jiny jazyk, ze bude nadavat jak napsat v tom novem neco, co je prece tak "jednoduche".

Az take peklo to nie je. Ja napr. na v jednom systeme pouzivam presne takyto nastroj. Proste stvorceky spajam sipockami, kazdy stvorcek ma svoju funkcionalitu a parametre. Len to hosi dotiahli do absurdnosti a musim naklikavat aj cislene konstanty. :-D

U nás se tomu říká nádraží. Už v malém programu je obrovské množství čar, takže se v tom nedá vyznat. O porovnávání a verzování škoda mluvit.

Právě o to jde, převést tvoji myšlenku v hlavě do nějaké uchopitelné potoby co nejefektivněji a nejsnadněji, nejlépe do 5 minut. Ne aby si se trápil buď s psaním textu anebo ještě hůř se zkoumáním IDE.

Pokud jde o mě, tak svou myšlenku nejefektivněji a nejsnadněji převedu do uchopitelné podoby pomocí pár desítek znaků abecedy, místo abych to ztvárňoval pomocí štětečku a barviček obrázky. "Záchod" nebo "pitná voda" ztvárním dost rychle a srozumitelně i obrázkem, ale "záchod jen pro personál" či "voda pitná jen po převaření" ztvárním obrázkem podstatně hůře a nesrozumitelněji, zatímco textová podoba je zhruba stejně "pracná" v obou variantách. Jiná situace nastává, pokud mám popsat nějakou sočástku - ale to je známá věc, že obrázek je vhodnějším nástrojem k zachycení stavu, zatímco jazyk je vhodnější k popisu dynamiky.

Podle mě je největší omezení programátorů to, že musejí datlovat jednotlivá písmenka

Človek musí obdivovať sira Sinclaira, ktorý toto vyriešil s predstihom 30 rokov. Utrel som si slzu pri spomienke na môj prvý počítač.

Na to aj ja s nostalgiou spominam.

Vy nepoužíváte Visual Assist X? Nebo napovídač v Eclipse?

Spolu s Cochtanem musim konstatovat - jeste ho mam schovanej

No programoval som jedneho casu v LabView

http://www.ni.com/labview/

je to trochu ine, vizualne programovanie, hlavne do labaku pri automatizacii meracej aparatury

Ja v LabVIEW programujem den co den.

Pro mě je unicode ve zdrojácích noční můra, opravdu nepotřebuju mít 5 různých typů mezer a 4 typy pomlček, které od sebe navzájem nejdou vizuálně rozpoznat. Nevím, jak bych psal znaky, které nejsou na klávesnici, to by bylo zbytečné zdržování. Já bych na současném stylu zapisování programů nic neměnil, je to jednoduché a hlavně funkční a vyzkoušené. Mnohem důležitější význam pro programátor má programovací jazyk a s tím spojený způsob přemýšlení, než to v jakých se zapisuje symbolech.

Lidský jazyk, taky používá jen pár desítek hlásek a stačí na vyjadřování daleko abstraktnější než umožňují programovací jazyky.

Ano, proto syntaxe a semantika. Trdlo.

V lidském jazyku je naprosto běžné, že si 2 mluvící "stejným" jazykem nerozumí...

Dle mého názoru to, že se programy zapisují v ASCII není zastaralý kompromis, ale završení dlouhotrvajícího vývoje.

Pokud mne paměť neklame, tak první písma byla obrázková (například právě egyptské hieroglyfy) a staletí ukázala, že pro rozumnou práci jsou nepraktická a špatně se čtou.

Navrhovat unicode pro programovací jazyky je v principu totéž, jako navrhnout přidání čínských znaků do češtiny. Já jsem přesvědčen, že tudy cesta rozhodně není - už tak je dost problém rozpoznávat O a 0, l a 1, ...

Pravděpodobně první písmo vzniklo v Sumeru a bylo klínové. Egyptské písmo prošlo značným vývojem (egyptská civilizace trvala přes 3000 let!), třeba démotické už své předchůdce moc nepřipomíná. No a sám uvádíte písmo čínské; ta více než miliarda lidí, která jej používá, si o něm určitě nemyslí, že by bylo nepraktické a špatně čitelné :-).

Úvahy o zrušení čínského písma se v historii už vyskytly (protože je opravdu velice náročné jej zvládnout a např. za celou dobu základní školní docházky se to nedá stihnout - porovnejte, kdy jste byli schopni přečíst cokoliv psané latinkou), ale v případě Číny by se tímto krokem odřezali od pokladů své historie.
Úspěšný obdobný krok se povedl v Turecku nebo ve Vietnamu, kde přešli na latinku a podle všeho se tam k původním písmům neplánuje návrat:-)

:) ale čínské písmo má jenom pár tahů(mnohem měné než je písmen v české abecedě) a ty tvoří vše... Navíc je každý obrazec tvořen přesně stanoveným postupem... znaky co vidíte jsou už slova ne písmena jako taková.

studie z Ciny a Taiwanu ukazaly ze maji mensi riziko ziskani Alzheimerovi choroby nez je tomu v zapadnich zemich.
zajimalo by me jestli je to i dusledek pouzivani cinskeho pisma?

to netušim. Podle mě je to spíšě životasprávou než písmem jako takovým...

Moznost pomoci klavesnice psat vseljake symboly ala unicode uz jednou v historii tu byla, viz tu a lepsi nahled tu.

koukam, ze nadcasove zavedli i tlacitka pro Facebook - vpravo nahore: "Like" a "Dislike" :)

Z roota se nam asi stava novy Blesk pro programatory. Sokujici titulek se snazi nalakat na nesmyslny clanek o nesmyslech :(
Ale aspon si pak clovek muze zlepsit naladu u diskuse :)

Tento článek je naprosto o ničem. Vypovídající hodnota nula.

Pokud bude třeba číst zdrojový kód, musí být čitelný, srozumitelný a jednoznačně určitelný. Přidat pár znaků, pokud se vyskytne skutečná potřeba? Proč ne. Ale zkusme dotáhnout myšlenku do konce.

Já budu používat operátory ř,ě,ů, Rus třeba "šč", na dalších národních klávesnicích se jistě najde také něco příhodného. A nikdo se nevyzná v tom co napsal druhý a už vůbec nebude vědět jak opravit chybu.
Většina nástrojů mi umožní napsat "í a=2 ůK" a přeložit to na
"if a=2 ; then echo ‘Je to OK‘" Rychlost psaní tedy bude stejná.

Použití barev pro zvýraznění je fajn, ale kdo tiskne nebo mailuje kód barevně? Co si počít, když bude kód nebarevný? Nebo když já ho prostě barevný nevidím? Už vidím ty debaty: "Tady máš červenou ( před zelenou (." "nemůžeš napsat modrou >.". Ani nezmiňuji, jak špatně by se to psalo.

BTW Takový překladač zdrojového kódu do národního jazyka s nápovědou a vysvětlivkami, by dokázal nahradit spoustu počítačové literatury.

To je nějakých pár desítek znaků, v dnešní době naprosto nevyhovující. Navrhuji rozšířit naši abecedu o obrázkové písmo.

A co daleko zavaznejsi problem, totiz omezeni celkovym poctem slov? Vezmete si jednoduchy priklad - slovo "soucin". Pokud pojmenujete promennou soucin, nemusi byt hned jasne, o jaky soucin a jakych typu se jedna. Muze to byt klasicky soucin, vnitrni soucin, vnejsi soucin, kartezsky soucin..

Jak je videt, je to tedy velmi svazujici. Bylo by prakticke vynalezt nova slova, a ta pouzivat misto techto nesmyslne dlouhych slovnich spojeni.

:-))

Feritové paměti jsem už v praxi nezažil :-)

Článek je divný. Když už autor tolik prosazuje unicode, překvapuje mě, že neřekl, že python3 Unicode podporuje:

>>> ěščřžýáíé = 1
>>> print(ěščřžýáíé)
1

prispevek je divny, proc mel zminit zrovna python3?

Protože by tady byla spousta komentářů o tom, proč neřekl, že unicode znaky se mohou používat například i v PHP nebo Javě? Mimochodem funguje to i v CSS.

Hlavne je ten clanek uplne o necem jinem, pripustime-li tedy, ze to cosi o necem je.

Počítač ZX Spectrum měl speciální klávesnici, pod každým písmenem byl i příkaz jazyka. Na displeji se zobrazoval jako slovo, ale v paměti byl pouze 1 byte. Zrychlilo to zápis programu i jeho interpretaci.

Opravdu to zrychlilo zápis programu?

- najít na klávesnici daný příkaz bylo očas dost zlouhavé
- napsat příkaz byla magie, která vyžadovala čarování s Extend, Symbol Shift, atd. Jako začatečníka mě mátlo třeba to, že příkazy >=, <> a <= bylo nutné zapsat také "magicky"
- ještě dnes mě výše uvedené děsí, když sednu ke spektru nebo pustím emulátor
- v těch časech jsem neměl s čím srovnávat, takže mi to docela vyhovovalo :)
- interpretace BASICu to zase výrazně nezrychlilo, takže ASM byl jasná volba

Ano, ten EXTEND+SHIFT nebyl moc sikovne vymysleny, mela tam byt specialni klavesa, neco jako "window" na dnesnich klavesnicich. Ale pokud jste ZX pouzival denne, nemel jste nejmensi problem s rychlym psanim; ovladl svuj nastroj a stal se mistrem...

Pak, existovaly upravene ROM, ktere obsahovaly tokenizer, pak clovek mohl psat po pismenkach a tokenizer v ROM to prevadel na tokeny a zpet.

...a nebo použít parametr kompilátoru -encode

To se ale prekladac choval presne podle specifikace, coz je lepsi, nez kdyby si nejak domyslel, v jakem kodovani ten zdrojak vlastne je :-)

Jak pise Kamil (zdravim!), porad existuje prepinac -encoding a co je dulezitejsi, tak ve vyslednem .class to uz bude bez ohledu na zdrojovy kod dobre (to se netyka komentaru, ale napriklad retezcovych literalu a podobneho svinstva).

Článok je trochu odveci (ako som pred pár dňami diskutoval na news:rec.arts­.sf.fandom), veľa moderných jazykov umožňuje zapísať aspoň identifikátory v unicode (napr. python3), a farba nie je zďaleka nič kacírske - http://www.colorforth.com/cf.htm je tu už dlho (a okrem toho, skoro pre každý jazyk existuje syntax highlighting...)

Monochromatické monitory sice neexistují, ale barvoslepost jen tak nezastará...

Barvoslepi programatori pujdou k lopate a ti ostatni budou diskutovat, jestli je lepsi pouzit + cervene nebo radsi zelene. A na vypisy si poridi barevne traktorovky.

Ono uplna farboslepost je velmi vzacna - najcastejsie clovek ma slabsi jeden fotoreceptor a nevie rozlisit niektore casti farebneho spektra, napr. zelenu a modru alebo zelenu a cervenu (vratane odtienov). Pre takych ludi farebny trojuholnik vyzera ako pasy rovnakych farebnych odtienov - cize ak zrovna nebudu mat v takych farbach text a pozadie, nebude im to robit ziadny problem.

Na druhej strane, nechcem si predstavit, ako "kvalitne" vidi tetrachromat obrazky na takom beznom LCD monitore....

Jak říkám - opět se tu vymýšlí dávno vymyšlené... Vizte ColorForth.

A co teprve nastroje typu diff, ktere budou muset nejak zvyraznit textove totozne zdrojaky, ovsem jinak obarvene ;-)

Ano, to bude sila. Akorat nevim, jestli by bylo treba zvyraznit rozdily mezi napr. cervenym a modrym zdrojakem pomoci barvy fialove nebo radsi cervenym a modrym srafovanim. V kazdem pripade, programatori budoucnosti budou potrebovat zrak pilota, perfektni vnimani barev a kalibrovane monitory.

Ascii mam ožna haldu nevyhod ale chtěl bych vidět někoho na jedné klávesnici pokrýt celé unicode

prosim, uz stacilo takychto clankov. od tohto autora som este nevidel jedinu originalnu myslienku ci clanok -- vsetko prezute kecy z netu, tentoraz mame vynimku, su to kecy z ACM :)

ale 99% diskutujících nemá ani znalostní, ani inteligenční předpoklady k tomu, aby problémy tohoto typu řešili. To nejlepší, co můžete udělat, je nepokoušet se to řešit vůbec. Těch všemožných paskvilů za uplynulých 15 let vzniklo snad už dost. Za těch 60 let se okolo počítačů vymyslelo spousta vychytávek, některé se ujaly, jiné ne, některé možná čeká jejich renesance, některé současné hity do 10 let zmizí v zapomnění. Jestli si snad někdo z vás myslí, že dokáže přijít na něco nového, tak je to jen důkazem, jak málo toho ví a jak se málo orientuje. Jakmile by se o to začal zajímat více a do hloubky, zjistil by, že něco podobného vymyslel někdo jiný 20 let před tím, než se dotyčný vůbec narodil, a že to vymyslel mnohem sofistikovaněji. Ale řízením osudu se to neujalo.
Dojímá mne, jak se autoři Pythonu a jiní každou chvíli vytasí s nějakou super novinkou, jež je ovšem jen trapnou karikaturou něčeho, co tu bylo už před dávnými lety. Když čtu některé meditace některých přispěvatelů zde na téma zavedení hieroglyfů místo normální abecedy z důvodu úspory při psaní a jiné nesmysly... kdopak ví, jestli se zamysleli, proč se příliš neujal třeba jazyk APL, nebo mnohem obecněji - proč píšeme latinkou/azbu­kou/řeckou/arab­skou abecedou a ne hieroglyfy... proč ve Smalltalku byl znak šipky vlevo raději nahražen dvojicí dvojtečka-rovná se...
A vůbec - dojemný je i podtitul článku - "při návrhu syntaxe nového jazyka"... Prosím vás, kolik běhá na této planetě lidí, kteří dokážou navrhnout nový jazyk? Tím myslím PŘÍNOSNÝ nový jazyk? Kdejaký nedovzdělaný čičmunda má pocit, že právě ten "jeho" jazyk světu ještě chyběl, tak nás o něj musí obohatit a spoustě dalším lidem tak pokud možno zkomplikovat práci, protože se vždycky najde nějaký trotl, který ten jazyk k něčemu opravdu použije a někdo jiný to po něm bude muset udržovat. Za uplynulých 15 let nevznikl ani jeden, ANI JEDEN jazyk, který by byl v něčem nějak přínosný, tj. jazyk, který by obsahoval nebo elegantněji řešil něco, co nebylo vyřešeno dostatečně elegantně v nějakém starším jazyku.
Myslím, že lidi by měli konečně přestat řešit kraviny a měli by se více věnovat tomu, s čím mají největší problémy - myšlení. Mám totiž neodbytný pocit, že současní programátoři jsou líní nejen psát, ale dokonce i myslet. A to je pro IT ta největší katastrofa!

Možná máš pravdu z hlediska teorie programování, ale z hlediska praxe může mít "nový" mikrojazyk výhodu v tom, že umožní lépe řešit nějaký konkrétní problém, kvůli kterému byl navržen. Pro některé účely je "plnotučný" jazyk prakticky nepoužitelný overkill, který je jen na škodu věci. Kdyby se každý autor vychytávky nechal zastavit tím, že možná za 60 let jeho vychytávka nebude potřebná, tak nemáme vychytávky žádné.

Nějaký příklad?
Ale to je nedorozumění. Oni ti současní autoři žádné nové vychytávky nevymýšlejí. Oni si to jen myslí - a s nimi tisíce dalších, kteří jsou přesvědčeni o tom, že k programování nepotřebují znát historii svého oboru, matematiku atp. A mají v podstatě pravdu - ovšem k tomu, aby mohli vymyslet něco nového nebo aby mohli posoudit smysluplnost nějakého přístupu, už tyto znalosti nezbytně potřebují. Taky jsem byl takový - když mi bylo 15. Ale čím více mi je, čím déle programuji a čím více typů problémů už jsem potkal, tím více si uvědomuji, že lidí, kteří jsou schopni přinést něco opravdu nového, je strašně málo. Že my - normální - pokud chceme vyniknout, měli bychom především studovat práce a myšlenky těch několika geniálních. Dám analogii:
Matematici vymyslí diferenciální a integrální počet, který můžete použít k výpočtu obsahů, objemů, ale také ke spoustě jiných věcí, jež s těmi obsahy a objemy na první pohled nijak nesouvisí - třeba k rozvoji funkcí do nekonečných řad, zjištění asymptotického chování atd... Vymyslí k tomu algebraické konstrukce, postupy, zápisy, terminologii, zavedou potřebné objekty a vysloví a dokážou věty, včetně předpokladů, za jakých lze to či ono provádět. Ale spoustě lidí se to zdá příliš komplikované, není jim to na první pohled hned jasné, museli by nad tím párkrát zapřemýšlet a to je pracné a zdlouhavé, tak to považují za nepohodlné a nepraktické. Místo toho čas od času někdo přijde s návodem, jak spočítat kus plochy pod parabolou, který pro hyperbolu není použitelný, že nějaká funkce má takový a takový mocninný rozvoj, aniž by ovšem řešil problém jeho konvergence a až někdo přijde na to, že při určitých hodnotách argumentu to nefunguje, tak se řekne - no jo, to je nějaké divné, ale hlavně že to funguje tam kde to potřebuju já... Všichni vždycky zaplesají nad tou "novou" "vychytávkou", která tolikrát chyběla, aniž by si uvědomovali, že kdyby bývali vynaložili trochu toho úsilí, tak by zjistili, že tohle všechno už za ně dávno vyřešili jiní a mnohem elegantněji. Jistě - po tesařovi nemůžeme chtít, aby si odvozoval z teorie pružnosti vzorce k výpočtu statiky střešních konstrukcí. Ale stejně tak si ten tesař nesmí na to dělat ty ambice, že na základě svých sporých znalostí fyziky a matematiky bude vymýšlet nějaké poučky o statice, posuzovat užitečnost tenzorového počtu apod. Na to nemá dost kvalifikace - může maximálně mektat do kvality dlátek, paliček apod. - a to ještě s tou výhradou, že by to měl být zkušený fachman a ne nějaké mejdlo, které nadává na nešikovnost a překonanost klasického hoblíku jen kvůli tomu, že je to nemehlo a nedokázal se naučit používat ho tak, jak se má.

Predstava ze existuje nejak vyrazne mnoho typu problemu z nichz kazdy vyzaduje svuj vlastni jazyk je myslim velkym omylem.

A co se praxe tyce, napsat si novy "mikrojazyk" jako sadu maker do lispu bude urcite radove snadnejsi nez psat novy jazyk. Samozrejme ze clovek co nikdy lisp nepouzival, nebo dokonce netusi co to lispova makra jsou (a pro ty co to netusi: jsou to programy co pisou jine programy. s makry v C to nema NIC spolecneho), to ihned odmitne, coz je chyba. Schopnost vytvaret specializovane "mikrojazyky" je totiz pro lisp typicka.

A pokud se ma jednat o neco supernenarocneho, je tady forth, ktery je primo idealni pro ruzne mikrokontrolery.

Nerikam, ze neni mozne vymyslet novy jazyk, ktery bude lepsi nez kterykoliv existujici, ale rikam ze to je TEMER nemozne. Zvlast proto ze 99% vsech "novych" jazyku jsou jen nescislnekrat opakovane variace na tema "C++, Java, C#" s rozdily, ktere pripadaji velke lidem co se chlubi tim ze umi "4 programovaci jazyky" (C, C++, Java, C#). Je to asi tak stejne jako kdyz se budu chlubit ze se plynne domluvim 4 jazyky a budou to: cestina, cestina s moravskym prizvukem, slovenstina a zahoracka slovenstina - ale je asi neco jineho kdyz nekdo umi cesky, anglicky, nemecky a cinsky, ze ano?

No aby se vymyslel jiný programovací jazyk, nesmělo by se vycházet z analytického jazyka jakým je angličtina, ale třeba z nějakého polysyntetického jazyka, jako je inuitština, což by umožnilo lépe propojit syntaxi se sémantikou a zavést operace nad programem, které by byly schopny program strojově modifikovat, program by mohl začít 'myslet' na základě vyhodnocování syntakticko-sémantických pravidel.

To je mysleno ironicky? Nebo je to vtip?

jen napůl :-) Eskymáci slova tvoří příponami a předponami tak, že sémanticky vyjadřují celé věty. Stejně jako například čeština minulý čas slovesa vytvoří příponou. Takže morfologický tvar slova určuje jeho i jeho sémantický obsah. V češtině třeba u slovesa čas a osobu, změnou přípony dosáhnete změny času i osoby. V inuitštině nejen čas, ale téměř všechny gramatické jevy. Jedno inuitské slovo je v překladu věta. A stačí jim na to cca 700 pravidel, výjimky skoro neexistují. Kdyby COBOL vymyslel nějaký eskymák, vypadal by úplně jinak :-)

A z toho nějak vyplývá

"...což by umožnilo lépe propojit syntaxi se sémantikou a zavést operace nad programem, které by byly schopny program strojově modifikovat, program by mohl začít 'myslet' na základě vyhodnocování syntakticko-sémantických pravidel.""

- nebo je tahle část příspěvku vtip? Zní to jako totální blábol.

No představte si, že v inuitštině popíšete nějaká data, které popisují nějakou situaci. Díky vhodné struktuře jazyka snadno poznáte co je kořen slova, a aniž byste znal jeho význam, na základě asi 700 gramatických pravidel bez výjimek a vztahů mezi nimi můžete automatizovaně odvozovat závislosti z textu.

Takže jestli to správně chápu, tak výhoda inuitštiny je snadné parsování a pravidelná gramatika, takže by se dala použít na automatické odvozování atd. místo nějakého formalizovaného jazyka vycházejícího např. z angličtiny. Dnešní programovací jazyky jsou na tom ale podobně - jsou naprosto odlišné od angličtiny, jenom si z ní vypůjčují pár slov (některé víc, jiné míň) - ale co se týká gramatiky, je to něco úplně jiného. Takže myslím, že jazyk od eskymáků by se lišil především tím, že by měl klíčová slova v jejich jazyce :)

Jazyk, kterým člověk mluví, může asi mít nějaký vliv na programovací jazyk co vymyslí, jeho filozofii - např. tipuju, že severoameričtí indiáni se svými polysyntetickými jazyky, které v podstatě nerozlišují podstatná jména od sloves (všechno je jakoby nějaký tvar slovesa, věc je určená tím, co dělá), by zvolili jako typový systém duck typing :)

Ano, to je možné. No dnešní procedurální programovací jazyky jsou po angličtině analytické. Taky nejpropracovanější je teorie bezkontextových gramatik vycházejících z modelu analytického jazyka, kde záleží na pořadí klíčových slov. I když téměř čistý polysyntetický programovací jazyk existuje - assembler. Počítač tedy 'myslí' na nejnižších úrovních polysynteticky. Což je vlastně zajímavé :-)

A ještě něco, struktura instrukce assembleru je odrazem struktury procesoru, takže nenese žádnou informaci o nějakém konkrétním algoritmu, ale struktura slova reálného polysyntetického jazyka je odrazem reality, takže jeho analýzou na základě gramatických jevů můžete z oněch slov získávat další informace o popisované realitě, analýzou syntaxe tak odvodíte další poznatky, které nejsou explicitně v zápisu vyjádřeny. Formalizací tohoto postupu byste se třeba dostal k sémantickému webu na základě částečného a strojového porozumění textu.

Myslím, že dost velký problém ve strojovém porozumění je, že stroj si sice text dokáže "přeložit", ale aby mu opravdu rozuměl, musel by umět přemýšlet v souvislostech podobně jako člověk - porovnávat si to se svými dosavadními vědomostmi a nějak si získané informace mezi ně zařadit. Zatím překladače umí obecný text (ne nějaký formální jazyk napodobující přirozený) docela dobře přeložit, ale nerozumí mu. To je zatím sci-fi kdekoliv, ne jenom na webu. Myslím, že automatické překladače na tohle dřív nebo později narazí - že na kvalitní překlad je potřeba vědět něco o tom, co překládám.

No když se podíváte na inuitské 'slovo-větu' jako na instrukci, můžete zkonstruovat 'symbolický' procesor pro ten jazyk, který bude měnit svou strukturu podle toho co uslyší ...

Mě to jako blábol nepřipadá, třeba v Pascalu něco podobného bylo už před čtyřiceti lety: write a writeln :-D

Skoda, ale realita. Pokud nemas nejaky kvalitni napad jak vetsine programatoru zmenit mozek a najednou jim umoznit proniknout do taju toho co je pro Biktopa normalni, tak ma proste Biktop smulu, bude opustena mensina.

Ti co umeli cist byli po vetsinu lidske historie take mensinou. Cela historie vedy a techniky je plna slepych ulicek, tezkopadnych reseni i uplnych nesmyslu. Spousta z nich se dlouhou dobu drzela, ale drive nebo pozdeji se lepsi reseni prosadi.
Na konci 19.stoleti byli zastanci letadel tezsich nez vzduch vysmivanou mensinou a i uznavani vedci prohlasovali ze nic tezsiho nez vzduch letat nemuze.

Kdyz pak vetsina "lepicu kodu" vyznava nazor typu: "cemu nerozumim to me urazi", sice je to smutne, ale verim, ze v budoucnosti se lide budou jazykum jako je C++ smat stejne, jako se dnes smejeme "futuristickym" kresbam z konce 19.stoleti, ve kterych lide, psi, i domy letaji na balonech a vzducholodich...

A ted realisticky: kvalitni napad mam, a ani neni nutne menit mozky :)

Staci programatory prinutit naucit se nejaky slusny jazyk. Jiste se najdou jedinci, kteri to nezvladnou vubec (jako vsude), ale vetsina to zvladne, a mala mensina to zvladne skvele.

Navic je to myslim dobry test schopnosti programatora - behem zkusebni doby dostane za ukol naucit se common lisp a napsat v nem nejakou komponentu - kdo to nezvladne, muze zkusit stesti jinde :)

Lepici kodu se musi smirit s tim ze ne kazdy muze byt architekt a navrhovat uzasne prevratne mostni konstrukce - nekdo proste nema na vic nez davat na sebe cihly, pripadne jezdit s nakladakem - tak to je, bylo a bude.

Stezovat si, ze ne kazdy dokaze "myslet v lispu" (nebo jinem "lepsim" jazyku) a proto je lisp spatny je jako tvrdit ze vypocty tuhosti mostni konstrukce sou blbost, protoze je vetsina lidi na stavbe nechape..

Jako programatori jsme ted v praveku, kde se valena klenba povazuje za moc slozitou a vsichni si svorne pobrukuji ze to je "teoreticka vymyslenost", ktera je k nicemu, kdyz prece zemljanku dokaze postavit kazdej a uplne v pohode staci.. :)

Panečku, to byl jazyk! Začínal řádkem
IDENTIFICATION DIVISION.
a končil příkazem
STOP RUN.
No, a mezi tím popis v takové "zjednodušené" angličtině, např.: A := B bylo nutno zapsat
MOVE B TO A.
což tedy byla věta, kterou nutno ukončit skutečně tečkou.
Dokonce jsme s jedním kolegou začali psát takový preprocesor, který by vyžadoval před každým příkazem PLEASE, a za příkazem THANK YOU.
např.
PLEASE, MOVE B TO A. THANK YOU.
Měl to tedy být takový silvestrovský žertík, ale kolega se pak odstěhoval a našel si práci jinde - a už jsme to nedotáhli do konce. Škoda...
Proti tomu je takový ALGOL (neřku-li C či C++) vyložený těsnopis. Co bys ještě chtěl, autore?

Tak MOVE A TO B mi přijde srozumitelnější než A := B. No a to PLEASE s THANK YOU by za mě mohl automaticky doplňovat editor. :-D
Zkus to dotáhnout do konce a nezapomeň i na jazykové varianty. Už to vidím: "Prosím tě. Přesuň A do B. Děkuji ti pěkně." :-D

No, tak ono to bylo myšleno, jako že tu prosbu a to poděkování bude nucen psát (datlovat) sám programátor. (V té době jsme ještě programy děrovali do štítků a žádný editor jsme k dispozici neměli.) A ten preprocesor měl fungovat tak, že PLEASE a THANK YOU odstraní a očištěný text pošle kompilátoru. Pokud by tam ale ta "kouzelná" slůvka chyběla, tak měl vynadat programátorovi za nezdvořilost, a každý příkaz jimi neobklopený měl označit jako FATAL ERROR :-))
A propos, jednalo se o stroj IBM 370 model 145 a nepoužívalo se kódovací tabulky ASCII, ale EBCDIC...

AWK preprocesor pro Vas slusny COBOL, jen ASCII, zadne UNICODE:

 awk '{sub(/^ *PLEASE, */,""); sub(/^ *THANK YOU[.] *$/,"");}' 

awk '{sub(/^ *PLEASE, */,""); sub(/^ *THANK YOU[.] *$/,""); print $0;}'

sed verze je jeste kratsi:

sed -e's/^ *PLEASE, *//' -e's/  *THANK  *YOU[.] *$//'

Sir Sinclair si byl vyse uvedeneho problemu vedom uz v 80 letech. Proto navrhl pocitac ZX-Spectrum tak, aby se program zapisoval po slovech, ne po pismenkach jak byva bezne zvykem... ;-)

Jinak, jsme konzervativni, ASCII mi plne vyhovuje a pokud si nekdo chce zivot komplikovat UNICODE znaky, nic proti tomu nemam. Kazdy svho stesti strujcem...

A vubec, UNICODE by se melo rozsirit o symboly pro klicova slova nejbeznejsich programovacich jazyku, podobne jako to mel BASIC na ZX-Spectru; tam byly prikazy (TOKENY) kododvany kody 128-255 z ASCII tabulky. Rozhodne by se mel v UNIOCDE tabulce objevit specialni symbol pro PRINT, printf, echo, while, repeat, until, atd, atd... ;-)

Jo, podobné úvahy jsou zaručeným receptem, jak vymyslet totální zbytečnost, která mi někdy v budoucnu způsobí akorát spoustu velkých komplikací... :-D Bohužel, někteří podobné věci myslí zcela vážně...

unicode snad podporuji vsechny rozumne jazyky .....
proc je u clanku symbol nejakeho smesneho tucnaka?

No třeba C nebo C++ podporují Unicode identifikátory jenom s nestandardním rozšíření GCC. A Unicode operátory v žádném používaném jazyku definovat nelze.

U toho tučňáka bych taky čekal spíš ASCII art :)

Ale lze, např. ve Scale. Viz. odkaz nahoře na knihovnu scalaz.

Už vidím, jak budu na své česko/anglické klávesnici loudit alfu, betu, gamu... :D asi to bude dobry důvod zůstat u ASCII. :)

Musel by sis koupit nejakou univerzalni, co ti bude znaky prekreslovat pri prepnuti i na klavesach. .)

A vubec, klavesnice je vlastne strasne omezujici, nebude lepsi program kreslit na tabletu???

Jj, na programování je nejlepší Optimus Maximus :)

Chtěl bych reagovat na Kampovu hypotézu o barvě jako součásti kódu.
Myslím si, že jde o totální nesmysl. Kolik knih o programování je tištěno barevně? A navíc co barvoslepí nebo daltonici? Ti by byli úplně v háji... Doufám, že tenhle nápad zůstane jen ve fázi nápadu :)

Prakticka ukazka UNICODE pri psani kodu:

http://en.wikipedia.org/wiki/ChinesePython

Nasel jsem jej v teto sbirce:
http://en.wikipedia.org/wiki/Non-English-based_programming_languages

Jeste jeden hezky priklad; maji tam klavesnici, ktera pripomina ZX-Spectrum, jen misto programovych tokenu tam maji nejake cinske znaky, pry nejake "radikaly":

http://en.wikipedia.org/wiki/Chinese_BASIC

Já osobně jsem velkým odpůrcem unicode v syntaxi jazyka. Pokud se objevuje v textech tak budiž, tam je to prostě potřeba. Ale v názvech proměnných to nemá co dělat. S čím ovšem s autorem článku souhlasím je občasná potřeba mít více symbolů.

Například výběr závorek je dost omezený - obyčejné, hranaté a složené. Obyčejné vyhradím na závorkování kvůli prioritě operací, hranaté pro pole a složené pro množiny. No, ale jak zapíšu seznam? Někdy se to řeší tak, že hranaté závorky jsou pro seznamy a pole je zapsáno jako množina a jen se "nějak" implementuje, že klíčem v té množině bude číselný index. V každém případě se zde jedná o "obcházení" limitu ASCII. Kdybych si do jazyka mohl nadefinovat další typ závorek, kupříkladu ostré závorky (ty z html tagu), mohl bych zapsat všechny tři typy "collections" nezávisle - pole ostrýma, seznam hranatýma, množinu složenýma. Jenže už se pak musím poprat s parsováním znaku menší a správným rozpoznáním kdy jde o znak menší a kdy jde o uvození pole.

Dalším příkladem jsou přiřazování. Máme tu obyčejné porovnání (v C ==), obyčejné přiřazení (v C =) a přiřazení výrazu (v C musím napsat jako funkci a předat pointer na ni). Některé jazyky to řeší jinak, například porovnání je =, přiřazení hodnoty je := atd. Někdy se to hemží těmi =, ==, :=, ::=, :=: až to hezké není.

Osobně bych nechtěl jít cestou APL, tam těch symbolů bylo až moc. Ale zrovna další typ závorek, znak pro zřetězení (aby se nepletl s plusem) a další znak nebo dva pro přiřazení bych vlastně ocenil. V mém "novém" jazyce (variace na LPC) si zatím pomáhám méně častými ascii znaky jako je $, # a @, ale nějak mu to na čitelnosti nepřidá. A přes problém závorek jsem se zatím nedostal, rozlišit zda je menší použito jako součást porovnání nebo párová závorka je zatím nad mé síly.

To v SBCL neznam. :-D Ale jinak pekna diskuse.

Jinak, pojem ,,kvalitni syntaxe'', to je taky mazec. Vubec neni vagni, je pekne absolutni, aby se o nem mohly psat clanky do Communications ACM.

a abych dodal, ... poetika onoho pojmu opet nejlip vynikne v CL, kde si cek muze kompletne preprogramovat reader.

Ani velikosti operacni pocitace, ani rychlosti procesoru...

Vysledkem jsou pak programy zpracovavajici video ktere veskery vstup naalokuji do pameti (ze Imagemagick ?!?) a jde to do swapu, nebo jsou zvoleny slozitostne nevhodne algoritmy takze se clovek vysledku nedocka.

Doufam ze mate nainstalovane potrebne fonty...

#อินคลูด <สตโดิ.ห>

อินต เมิน(อินต ารกค, เคร **ารกง)
{
ปรินตฟ("สวัสด­ีครับโลก");
}

BLEKu, zkontroluj mi ze jsem neudelal preklep! Instrukci sadu Z80 jsi tehda taky dal bez dokumentace, a thajska abeceda urcite neni slozitejsi nez instrukcni sada Z80 :)

Krasa! Ale pro lepsi vizualni dojem doporucuji Telugu..

Díky zmíněnému konzervatismu můžeme dnes říci, že lecos jakž takž funguje. Pokud bychom dopřávali sluchu kdejakému "progresivnímu" hošíkovi jako je třeba autor článku, sice bychom se plácali po zádech při každé skvělé mega super hyper cool ptákovině, ale dělat by se s tím nedalo vůbec a chudáci uživatelé...
Chvála Bohu za to, že jsme tak konzervativní!

+1 Souhlas.

Nijak se nechci dotknout autora, který evidentně ví o čem píše, nicméně rvát další sadu unicode znaků přímo do kódu, nebo se dokonce rvát barvy kódu přímo do syntax je absolutní úlet.

Autor si nejspíš neuvědomuje, že ty znaky musí programátor pořád ještě psát na klávesnici. A i kdyby nemusel, pořád by musel mít v hlavě další obrovskou zásobu znaků, které cosi provádějí. Výsledkem by tak mimo jiného mohl vzniknout další write only jazyk stejně jako perl.

... ale uplne jinym smerem :-) Dneska tady mame x siroce pouzivanych jazyku, kde x je zhruba 15(!), ale pouze jeden jediny z techto jazyku zvlada slusne programovat paralelni ulohy. Je to Erlang.

Zatimco ostatni jazyky se predhaneji (zda se) v tom, jakym n-tym zpusobem napsat zakladni ridici konstrukce (odsazeni, if-then-else, if() {}else{}, atd.), tak se zatim IMHO dost zapomelo na to, ze dneska jsou zcela bezne vicejadrove procesory (8 jader v pocitaci neni zadna vyjimka) a naprosta vetsina aplikaci si neco masti na tom jednom jedinem jaderku.

A je to hodne prave veci programovacich jazyku, ktere paralelni programovani moc nepodporuji. Java/Python/Scala atd. sice programatora odstinily od nutnosti resit si alokaci a dealokaci pameti, coz je jiste fajn, ale podpora pro komunikaci mezi paralelne "zijicimi" objekty vyresenu moc dobre nemaji - jen na nejnizsi synchronizacni urovni, coz v praxi jen vede k obtizne detekovatelnym deadlockum :-)

Takze tady je urcite jeste velky prostor pro vyvoj a Erlang ukazal, ze to skutecne jde - vykonny jazyk nasazovany v praxi (na rozdil od ruznych spise akademickych pokusu o messaging).

Neni to tak tragicky. Java ma velmi dobrou podporu threadu uz 15 let. Scala ma i ty tvoje milovane aktory (akka framework).

BTW nevim jestli si v Erlangu nekdy delal, ale muze to byt docela opruz.

To je prave to, co jsem mel na mysli ;-) Ano, Java podporuje thready a zakladni synchronizacni mechanismy mezi nimi (+ synchronizaci na urovni nekterych typu trid, treba kolekci), ale to je podobne jako kdyz reknu, ze C/C++ dobre podporuje praci s pameti - skutecne podporuje, akorat si to malloc(), free() a new musim sam osetrovat a hlidat.

To stejne je s thready - pracovat s nimi umim, ale odladeni aplikace, kde bezi skutecne mnoho threadu (nemyslim ted "stejnych" threadu ve smyslu napriklad mnozstvi servletu delajicich to same), je dost obtizne a tady vidim malou podporu - nehlede na to, ze thready jsou uz z podstaty pod jednou VM a dneska se spise zada reseni, kde se daji "bezici objekty" (procesy/thready) prehazovat mezi masinami bez toho, abych si toho jako programator musel nejak moc vsimat (a J2EE reseni je moc kanon na vrabce ;-).

V Erlangu jsem zkousel pravda jen jednoduche veci, ale chystam se do nej vic proniknout, protoze takovy ejabberd me pripadne jako dost vychytany (na to, kolik zvladne dotazu a na jakem HW :-) A ano - tvurci Erlangu taky evidentne chteli nektere ustalene syntakticke veci vylepsit :-)

Ja s thready nemam problem. Chce to ale disciplinu a trochu jiny styl programovani (navrh, assertions, profiling, izolace modulu). Erlang se ti rozhodne nevyplati pokud nemas aspon 32 jader. Pod touhle hranici jsou lepsi thready.

Clustering v Jave jde udelat i bez J2EE.

Mimochodem - za nějaké dva roky slibuje AMD uvedení procesoru s 20 jádry - je to tedy zatím spíše následník serverového Opteronu, nicméně na stejnou dobu plánuje deset jader do desktopu.

Mé čajové lístky ve shodě s kávovou sedlinou tvrdí, že počet jader teď poroste podobně jako frekvence před lety. Těch 32 jader tady bude za chvíli...

Chystáte seriál o Erlangu? To by bylo fajn :-)

A co třeba jazyk Clojure?

Zajímavé také bude, jak si v následujících letech povede Data Parallel Haskell.

Osobně jsem si udělal průzkum a jako nejlepší se mi zdá D, kterému se taky chci věnovat.

Trochu podrobností; http://kitakitsune.org/D/

Unicode je v něm samozřejmě podporováno.