Hlavní navigace

Názory k článku Programovací jazyk TCL

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 7. 2005 7:55

    Petr Mach (neregistrovaný)
    Jsem rád, že se tu oběvuje článek o jazyku TCL, byl to zajímavý jazyk, i když je dnes už překonaný. Bude poučné si o něm něco přečíst. Nezkušené zájemce o programování ale chci upozornit, že dnes tu jsou modernější jazyky, které jsou užitečnější a které si za svých předchůdců, jako např. TCL/TK vzali to nejlepší a řadu dalších dobrých věcí přidali.

    Co se týče TCL, tak většina uvedených vlastností se shoduje s vlastnostmi jazyka Python. Až na pár výjimek, jako je ta podivuhodná syntaxe, která mate začátečníky. Cílem autorů Pythonu je nopak co nejčitelnější a nejběžněji používaná syntaxe. Dále Python stejně jako TCL nemá statické typy (tedy typ sdružený s proměnnou, která se předem musí deklarovat), ale narozdíl od TCL má silné typování (typy jsou sdružené s hodnotou a nedochází k automatické konverzi řetězec-číslo a pod.), takže nemá problémy při zpracování matematických výrazů a podobně. Je to ideální kompromis mezi zachováním dynamičnosti jazyka a typové kontroly pomáhající odhalit řadu chyb v programu a usnadnit tak jeho odladění. Python je také, na rozdíl od TCL, objektový jazyk, umožňuje ale i psát programy procedurálním stylem.

    Co se týče TK, tak o něm si myslím, že to je zastaralý, v linuxu ošklivý a těžkopádný GUI toolkit. Nicméně i Python ho používá jako svůj výchozí GUI toolkit (je např. součástí distribuce Pythonu pro Windows), kdyby o něj někdo mermomocí stál. Pro Python však existuje řada lepších GUI toolkitů, jako např. GTK (používá GNOME, Gimp, Abiword, linuxový Firefox a řada dalších aplikací) nebo Qt (používá KDE) a TK se proto v Pythonu moc nepoužívá.
  • 19. 7. 2005 8:14

    Pavel Tišnovský
    Programovací jazyky, zejména ty interpretované, se opravdu vyvíjí docela rychle, podle mě je však Tcl pro "amatéry" poměrně jednoduchý a zvládnutelný a pro "profesionály" díky LISPovskému pojetí kódu velmi mocný jazyk. U Pythonu je docela problematická jeho 2D syntaxe, která právě začátečníkům bude dělat problémy, například při kopírování cizího kódu (přes schránku, posílání částí kódů e-mailem apod.) - ostatně kopírováním kódu se tvoří tak polovina aplikací ve VBA, což je také jazyk/prostředí pro amatéry, tj. pro lidi, kteří programují pouze pro zábavu nebo pro urychlení své práce, ale není to hlavní náplní jejich práce.

    Tcl má velmi jednoduchou syntaxi, což potěší všechny, kdo ho používají jako svůj druhý nebo třetí jazyk, grafický interpreter (shell) Wish, kde se dá interaktivně vytvářet GUI a nerozlišuje mezi programovým kódem a daty (jako LISP). Také nesmíme zapomenout na možnost jednoduchého zabalení do další aplikace, která Tcl může používat jako interpret (teď mě napadá například WinCVS).

    Tk je sice (alespoň co se týče doby vzniku) na první pohled zastaralý, ale v kombinaci s Tcl velmi výkonný. Opravdu je to asi nejjednodušší toolkit na vytváření GUI s některými pokročilými vlastnostmi - viz například pojetí canvasu. Tk používá nejenom Python, ale i Perl a hodně programů napsaných v C-čku. Pravda, na Linuxu může Tk někomu připadat ošklivý, ale mě zase připadne ošklivé a strašně obrovské GTK na Windowsech.

    Samozřejmě nemám nic proti Pythonu, je v něm udělána řada skvělých utilit, ale i Tcl/Tk má při programování své místo a ohánět se jeho stářím není vhodné (to stejné bych přece mohl říct o vi/vim, což by Tě asi naštvalo).
  • 19. 7. 2005 9:37

    Petr Mach (neregistrovaný)
    Můj pohled je jiný. Imho pro lidi co TCL/TK neznají je investice do jeho naučení se zbytečná. Zvláště co se amatérů týče. Profesionálovi to může pomoci k rozšíření obzorů a naučit ho to trochu jinému pohledu na programování. Tou 2D syntaxí zřejmě myslíš povinné odsazování. To je vlastnost, která má své jasné klady i zápory. Imho ty klady převažují, ale je to subjektivní hodnocení. Co se týče VBA a kopírování, tak mohu říct, tím spíš. Čím víc dochází k častému znovupoužití (navíc cizího) kódu, tím víc je významější jeho přehlednost a čitelnost a to je právě to, čemu povinné odsazování napomáhá. Jestli je syntaxe TCL je jednoduchá, to je otázka. Má málo pravidel, to je pravda, ale podle mě to dělá programování složitější. Je to jako řeč. Jazyk kde je málo slov se člověk určitě naučí snáz, ale vyjadřovat v něm své myšlenky je pak komplikovanější. A programování, to je vyjadřování svých myšlenek, mluva k počítači, kterému tím říkáme, co po něm chceme. Ale ani jazyk s příliš mnoho slovy není z tohoto hlediska vhodný. Nejlepší je taková zlatá střední cesta. Jedno zlaté UNIXové pravidlo říká, udělej to tak jednoduše, jak jen je to možné, ale ne jednodušeji. A u TCL se mi to zdá již přehnané. Zabalení TCL do jiné aplikace jako jejího skriptovacího jazyka je jistě velmi užitečné, ale touto vlastností oplývá i Python, viz třeba Gimp nebo Blender a jestli se nepletu, tak jeho interpret obsahuje i OpenOffice.org. Co se týče TK, tam se asi neshodneme. Nelíbí se mi ani po stránce vzhledu (což je velmi významné, protože podle toho aplikaci posuzují její uživatelé) ani po stránce použitelnosti z pohledu programátora. Zmíněné GTK je např. TK hodně ovlivněn a inspirován, ale je dotažen poněkud dál už v dnes beznadějně zastaralé verzi 1.x. O to víc v mnohem lepší verzi 2.0 s Pango (práce s fonty), ATK (accesibility, přístupnost pro různě postižené uživatele) či Glade+libglade (WYSIWYG GUI návrhář, který návrh GUI ukládá do XML souboru a umožňuje měnit GUI aplikace za chodu, bez nutnosti zásahu do kódu aplikace) a podobně. Přitom použití GTK je snadné. Například popisek s větším tučným písmem se udělá takto:
    label=gtk.Label()
    label.set_markup("Popisek:")
    
    Kde práci s fontem jednoduše zajišťuje PangoML, což je jednodušší, HTML podobný, jazyk. Co se týče GTK ve windows, tak je pravda, že jeho defaultní vzhled je větší, než je tam obvyklé (hůře vidící lidé ocení). Zřejmě si ale přehlédl, že součástí GTK pro windows je prográmek (v adresáři bin, jmenuje se gtkthemeselector.exe) pro přepínání témat (vzhledů. skinů) a že kromě defaultního vzhledu jsou jeho součástí další vzhledy, třeba redmond95 nebo wimp, které by ti mohli vyhovovat. Což je mimochodem další z výhod GTK. TCL/TK má při programování své místo, to nepopírám, už jen kvůli údržbě již napsaného kódu. Můj příspěvek jen chtěl upozornit nezkušené zájemce o programování, že TCL je veterán, o kterém můžeme psát s nadšenou nostalgií, ale přeci tu jen už jsou vhodnější a modernější programovací jazyky. Zkušení programátoři přínos TCL zajisté dovedou posoudit sami. Určitě se najdou tací, které TCL osloví a něco jim přinese, ale přiznejme si, bude jich pravděpodobně výrazná menšina. Co se týče Vi, to je skutečně zastaralé a nelze nikomu doporučit. Vim zastaralý rozhodně není, vyvíjí se a jiné editory v některých ohledech překonává. Přesto, a nebo právě proto, bych souhlasil, že Vim není vhodný pro amatéry, na to je příliš komplikovaný a vlastnosti které nabízí amatéři nedokáží využít a ocenit. Nicméně, zastaralost bych neodvíjel od času vzniku, ale od toho, jaká ta věc je. I teď v roce 2005 může vzniknout nový jazyk, který bude používat zastaralé koncepty a může tak klidně být považován za zastaralý a překonaný. A TCL/TK podle mě takové je, přestože bylo ve své době inovativní a řada modernějších jazyků se jím nepochybně nechala inspirovat.
  • 19. 7. 2005 12:53

    Miloš Kafka (neregistrovaný)
    Docela chápu vaše nadšení Pythonem.Zvláště z pedagogického hlediska jde o jazyk povedený a vhodný i pro začátečníky a mohl by konečně nahradit Pascal na školách. Ale snazší tvorba GUI než v kombinaci Tcl/TK už neexistuje - alespoň ne při psaní příkazů. Rozhodně bych nemluvil o nepoužitelnosti z hlediska programátora. Vytvoření GUI pomocí grafického vývojového prostředí nebo builderu v jiných knihovnách je sice ještě jednodužší, ale pouze pro GUI statické; dynamický formulář v něm vytvoříte těžko - a příkazy pro jejich složitost skoro nikdo neumí; proč taky. Výsledkem je často neuvěřitelně toporné ovládání mnoha programů, které u databází připomíná ubohé formuláře HTML. Estetické hledisko sice je důležité, ale pouze na první pohled. Při denní práci je důležitější variabilita a přímočaré ovládání. Např. možnost výběru zobrazených sloupců prostým zatržením ocení uživatel víc, než hezký rámeček. A neustálé přehmatávání mezi myší a klávesnicí vás při hromadné editaci přivede do blázince.

    A tak máme velmi dynamické skriptovací jazyky, které omezujeme statickým GUI, protože nemohu generovat příkazy, pokud je neznám. TCL/TK umožňuje snadné vytvoření GUI i bez těchto omezujících berliček. Myslím, že do koše ještě nepatří.

    Jinak by se autor mohl na konci seriálu krátce zmínit i o rozšiřující knihovně Tktable, příp. dalších.

    A ještě krátké upozornění pro zájemce: Nakladatelství \"Computer Press\" připravuje k vydání knihu \"Průvodce programovacími jazyky TCL/TK\".
  • 19. 7. 2005 13:27

    Pavel Tišnovský
    S tou dynamickou změnou formulářů máte pravdu. O Tktable se v některém z dalších pokračování určitě zmíním, ještě však nevím, do jaké hloubky (příklad určitě bude).
  • 20. 7. 2005 12:14

    Petr Mach (neregistrovaný)
    Vytvoření GUI pomocí grafického vývojového prostředí nebo builderu v jiných knihovnách je sice ještě jednodužší, ale pouze pro GUI statické; dynamický formulář v něm vytvoříte těžko - a příkazy pro jejich složitost skoro nikdo neumí; proč taky.

    To je otázka. Já si občas navrhuji GUI v Glade, protože je to pěkná skládačka a člověk si s tím může pohrát a když ho mám vytvořeno, napíši jej pomocí příkazů. Imho ty příkazy nejsou v případě GTK složité. Dynamické GUI v GTK není problém udělat, stejně jako si napsat vlastní widget.

    Estetické hledisko sice je důležité, ale pouze na první pohled. Při denní práci je důležitější variabilita a přímočaré ovládání. Např. možnost výběru zobrazených sloupců prostým zatržením ocení uživatel víc, než hezký rámeček. A neustálé přehmatávání mezi myší a klávesnicí vás při hromadné editaci přivede do blázince.

    On ten první pohled bývá docela důležitý a pěkný vzhled je důležitý i potom. Ergonomie UI je samozřejmě také důležitá, stejně jako podpora pro různě postižené uživatele a podobně. V ničem z toho GTK nezaostává, spíše naopak.

    A tak máme velmi dynamické skriptovací jazyky, které omezujeme statickým GUI, protože nemohu generovat příkazy, pokud je neznám. TCL/TK umožňuje snadné vytvoření GUI i bez těchto omezujících berliček. Myslím, že do koše ještě nepatří.

    S tímto nesouhlasím, protože apriori předpokládáte, že u TK se příkazy znají, u GTK ne a z výhody GTK (k dispozici je návrhář GUI) se snažíte dělat nevýhodu. Ale tak to není. API GTK knihovny v Pythonu je velmi jednoduché a intuitivní, až na TreeView a související a programátor v Pythonu tak má k dispozici možnost psát jak dynamické GUI stejně jako v TK (pomineme, že já si o jednoduchosti TK myslím něco jiného, protože mi jeho koncepce nevyhovuje) tak možnost jednoduché navrhování statického GUI v návrháři. Krom toho lze tento přístup kombinovat. Můžete si napsat svůj vlastní dynamický widget a ten zasadit do GUI navrženého v Glade.

    TCL/TK umožňuje snadné vytvoření GUI i bez těchto omezujících berliček.

    Ostatně, můžeme učinit pokus. Dejte sem prosím krátký charakteristický příklad dynamického GUI v TCL/TK a uvidíme jak půjde implementovat v Python/GTK.
  • 19. 7. 2005 9:39

    Petr Mach (neregistrovaný)
    Omlouvám se za přdchozí špatně zformátovaný příspěvek.

    ======================================================

    Můj pohled je jiný. Imho pro lidi co TCL/TK neznají je investice do jeho naučení se zbytečná. Zvláště co se amatérů týče. Profesionálovi to může pomoci k rozšíření obzorů a naučit ho to trochu jinému pohledu na programování.

    Tou 2D syntaxí zřejmě myslíš povinné odsazování. To je vlastnost, která má své jasné klady i zápory. Imho ty klady převažují, ale je to subjektivní hodnocení. Co se týče VBA a kopírování, tak mohu říct, tím spíš. Čím víc dochází k častému znovupoužití (navíc cizího) kódu, tím víc je významější jeho přehlednost a čitelnost a to je právě to, čemu povinné odsazování napomáhá.

    Jestli je syntaxe TCL je jednoduchá, to je otázka. Má málo pravidel, to je pravda, ale podle mě to dělá programování složitější. Je to jako řeč. Jazyk kde je málo slov se člověk určitě naučí snáz, ale vyjadřovat v něm své myšlenky je pak komplikovanější. A programování, to je vyjadřování svých myšlenek, mluva k počítači, kterému tím říkáme, co po něm chceme. Ale ani jazyk s příliš mnoho slovy není z tohoto hlediska vhodný. Nejlepší je taková zlatá střední cesta. Jedno zlaté UNIXové pravidlo říká, udělej to tak jednoduše, jak jen je to možné, ale ne jednodušeji. A u TCL se mi to zdá již přehnané.

    Zabalení TCL do jiné aplikace jako jejího skriptovacího jazyka je jistě velmi užitečné, ale touto vlastností oplývá i Python, viz třeba Gimp nebo Blender a jestli se nepletu, tak jeho interpret obsahuje i OpenOffice.org.

    Co se týče TK, tam se asi neshodneme. Nelíbí se mi ani po stránce vzhledu (což je velmi významné, protože podle toho aplikaci posuzují její uživatelé) ani po stránce použitelnosti z pohledu programátora. Zmíněné GTK je např. TK hodně ovlivněn a inspirován, ale je dotažen poněkud dál už v dnes beznadějně zastaralé verzi 1.x. O to víc v mnohem lepší verzi 2.0 s Pango (práce s fonty), ATK (accesibility, přístupnost pro různě postižené uživatele) či Glade+libglade (WYSIWYG GUI návrhář, který návrh GUI ukládá do XML souboru a umožňuje měnit GUI aplikace za chodu, bez nutnosti zásahu do kódu aplikace) a podobně. Přitom použití GTK je snadné. Například popisek s větším tučným písmem se udělá takto:

    <pre>
    label=gtk.Label()
    label.set_markup("<big><b>Popisek:</b></big>")
    </pre>

    Kde práci s fontem jednoduše zajišťuje PangoML, což je jednodušší, HTML podobný, jazyk.

    Co se týče GTK ve windows, tak je pravda, že jeho defaultní vzhled je větší, než je tam obvyklé (hůře vidící lidé ocení). Zřejmě si ale přehlédl, že součástí GTK pro windows je prográmek (v adresáři bin, jmenuje se gtkthemeselector.exe) pro přepínání témat (vzhledů. skinů) a že kromě defaultního vzhledu jsou jeho součástí další vzhledy, třeba redmond95 nebo wimp, které by ti mohli vyhovovat. Což je mimochodem další z výhod GTK.

    TCL/TK má při programování své místo, to nepopírám, už jen kvůli údržbě již napsaného kódu. Můj příspěvek jen chtěl upozornit nezkušené zájemce o programování, že TCL je veterán, o kterém můžeme psát s nadšenou nostalgií, ale přeci tu jen už jsou vhodnější a modernější programovací jazyky. Zkušení programátoři přínos TCL zajisté dovedou posoudit sami. Určitě se najdou tací, které TCL osloví a něco jim přinese, ale přiznejme si, bude jich pravděpodobně výrazná menšina.

    Co se týče Vi, to je skutečně zastaralé a nelze nikomu doporučit. Vim zastaralý rozhodně není, vyvíjí se a jiné editory v některých ohledech překonává. Přesto, a nebo právě proto, bych souhlasil, že Vim není vhodný pro amatéry, na to je příliš komplikovaný a vlastnosti které nabízí amatéři nedokáží využít a ocenit. Nicméně, zastaralost bych neodvíjel od času vzniku, ale od toho, jaká ta věc je. I teď v roce 2005 může vzniknout nový jazyk, který bude používat zastaralé koncepty a může tak klidně být považován za zastaralý a překonaný. A TCL/TK podle mě takové je, přestože bylo ve své době inovativní a řada modernějších jazyků se jím nepochybně nechala inspirovat.
  • 19. 7. 2005 13:25

    Pavel Tišnovský
    Ano, 2D syntaxí mám na mysli odsazování, které je součástí syntaxe jazyka - po mých dávných zkušenostech se soubory Makefile, kde jeden editor bez varování přepisoval tabulátory na mezery, mám k tomuto druhu vyznačování syntaxe dost velký odpor, i když na druhou stranu musím přiznat, že je uživatel donucen používat alespoň nějaký styl. Na druhou stranu je zavedení typovosti proměnných (resp. hodnot) pro začátečníky i pokročilejší uživatele vhodné, s tím naprosto souhlasím.

    Všimli jste si u GTK a dalších toolkitů primárně zaměřených na C/C++/Javu té neohrabanosti při vytváření GUI? Buď to děláte programově, což je poměrně složité, nebo se používají strašně komplikované XML soubory (takže uživatel se kromě daného programovacího jazyka musí ještě učit XML). Zato Tcl/Tk je v tomto ohledu elegantnost sama - samotný zápis programu, který okno/dialog vytváří, je tak primitivní, že je možné ho považovat za určitý druh resource. Přitom jeho čtení provádí sám interpreter, který nemusí být nijak rozšířen (ani o bajt kódu). A díky snadné substituci řetězců se může mapování dynamicky měnit nejenom při běhu programu, ale už při natahování "resource" z externího souboru!

    Ostatně ta substituce (resp. rovnost řetězec=příkaz) není často zmiňovaná, ale dají se pomocí ní vytvářet i velmi složité konstrukce, podobně jako v LISPu (vím, že pořád zmiňuji stařičký LISP, ale stále jde o prakticky nejmocnější dynamický jazyk, kterému se ostatní programovací jazyky postupně přibližují - viz Python a Ruby). Tcl je ve své podstatě jenom převléknutí LISPu do líbivějšího kabátku, i když autor tohoto jazyka kupodivu vycházel z úplně odlišných počátečních podmínek (a nakonec mu z toho vyšel skoro-LISP).

    ps: s tím Vim to bylo jen takové přirovnání k té časové zastaralosti, mám ho rád, jak je ostatně patrné z mých článků o něm.
  • 20. 7. 2005 12:27

    Petr Mach (neregistrovaný)
    po mých dávných zkušenostech se soubory Makefile, kde jeden editor bez varování přepisoval tabulátory na mezery, mám k tomuto druhu vyznačování syntaxe dost velký odpor

    Když jsem s Pythonem začínal, tak jsem z toho měl také obavy a tuto vlastnost jsem odsuzoval. Ale během používání jsem pochopil, že ty obavy jsou liché a že přínos je velký. Funguje to.

    Všimli jste si u GTK a dalších toolkitů primárně zaměřených na C/C++/Javu té neohrabanosti při vytváření GUI?

    To jsem si opravdu nevšiml.

    Buď to děláte programově, což je poměrně složité

    Není, já to dělám běžně.

    nebo se používají strašně komplikované XML soubory (takže uživatel se kromě daného programovacího jazyka musí ještě učit XML)

    To není pravda. XML popisující GUI je výsledkem WYSIWYG návrháře Glade. Programátor s obsahem XML souboru vůbec nepřichází do styku. Obávám se, že k elegantnosti návrhu GUI v Glade má TCL/TK hodně daleko a programovou cestu jsem ochoten na demonstrativních příkladech porovnat, domnívám se, že to tak není, ale ať to každý posoudí sám.

    Ostatně ta substituce (resp. rovnost řetězec=příkaz) není často zmiňovaná, ale dají se pomocí ní vytvářet i velmi složité konstrukce, podobně jako v LISPu

    Ty složité konstrukce jsou pak nepřehledné a těžko čitelné, jsou příčinami chyb a stěžují údržbu kódu. Jsem příznivec jiného stylu programování. Myslím si, že složitou konstrukci je naopak lepší rozepsat na několik jednoduších, protože program je pak snáze pochopitelnější a přehlednější, což po měsíci ocení nejen autor kódu, ale i všichni, kdo to bude z nějakého důvou číst po něm.
  • 20. 7. 2005 12:51

    Petr Mach (neregistrovaný)
    http://wraith.iglu.cz/python/ukazky/gui.checkbox/checks.py.html

    Odkaz vede na demonstrační ukázku. Je to obrázek mini GUI programu i s jeho kódem. Program obsahuje 5 zatrhávacích tlačítek pod sebou a jedno tlačítko. Při stisknutí tlačítka se vypíše na terminál, která tlačítka jsou zatržena. Můžete předvést implementaci v TCL/TK?
  • 20. 7. 2005 15:04

    Pavel Tišnovský
    Já bych to v Tcl/Tk napsal například následovně - stačí pomocí copy&paste vložit do Wishe, nebo z toho udělat celý skript (potom se ještě vytváří okno). Je ale fakt, že to vyčíslení hodnoty globální proměnné by šlo obejít například přes pole hodnot, které by se specifikovaly už při vytváření seznamu:

    lappend seznam [checkbutton .prvni -text "První"]
    lappend seznam [checkbutton .druhy -text "Druhý"]
    lappend seznam [checkbutton .treti -text "Třetí"]
    lappend seznam [checkbutton .ctvrty -text "Čtvrtý"]
    lappend seznam [checkbutton .paty -text "Pátý"]
    foreach i $seznam {pack $i}

    button .tisk -text "Tiskni" -command {tisk $seznam}
    button .konec -text "Konec" -command {exit}
    pack .tisk .konec

    proc tisk {seznam} {
    foreach i $seznam {
    set var [$i cget -variable]
    global $var
    set f [expr $$var]
    if {$f==1} {set answer je} {set answer není}
    puts "[$i cget -text] $answer zatržen"
    }
    }
  • 20. 7. 2005 20:03

    Petr Mach (neregistrovaný)
    No, takže si to shrňme.

    1) Není to ekvivalent mého programu protože to není spustitelný program.

    2) Používá to globální proměnnou, to je ale vcelku prasácký přístup, ona zmiňovaná zastaralá koncepce. U něčeho náročnějšího nepoužitelný přístup. Lze to prý obejít, možná, ale neobešel jste to. Pravděpodobně by to bylo složité a tím méně přehlednější, srozumitelnější a pochopitelnější. Přičemž já osobně právě na tyto vlastnosti kladu velký důraz, protože snižují pravděpodobnost vzniku chyb a snazší a rychlejší odladění aplikace.

    3) Je v tom nějaká chyba, stisknutí tlačítka Tiskni vyvolává chybové hlášení.

    4) Ten handler je hodně hodně podivný, srovnejme si je:
    PYTHON/GTK:
    
    def printStatus(button, checks):
        for check in checks:
            if  check.get_active():
                stat = "je zatržen."
            else:
                stat = "není zatžen."
            print check.get_label(), stat
    
    TCL/TK:
    
    proc tisk {seznam} {
        foreach i $seznam {
            set var [$i cget -variable]
            global $var
            set f [expr $$var]
            if {$f==1} {set answer je} {set answer není}
            puts "[$i cget -text] $answer zatržen"
        }
    }
    
    Snad už je jasné, proč si myslím, že: Nelíbí se mi ... ani po stránce použitelnosti z pohledu programátora. Jestli to dokážete, zkuste se na ty dvě ukázky podívat očima začátečníka (na které jsem se obracel). Co mu asi přijde srozumitelnější a intuitivnější? To co je nutné v TCL/TK opravdu nelze považovat za elegantnost samu, jak jste napsal, právě naopak. Zjišťovat stav tlačítka pomocí tří příkazů, globální proměnné a ještě vyhodnocováním výrazu, to je úplně mimo. V moderním toolkitu něco takového musí být dostupné jako snadno čitelná stavová proměnná toho tlačítka.

    5) Vzhled může posoudit každý sám:
    http://wraith.iglu.cz/python/ukazky/gui.checkbox/gtk-tk.png

    Tohle je takový první level. Troufnete si na level 2, to jest přizpůsobit ten kód tak, aby výsledek byl uživatelsky přívětivý? Tedy aby položky měly accelerátory, tlačítka ikonky a pod? To, že GTK je skinovatelné a standardní tlačítka se řídí podle locale, to budeme asi muset TK odpustit, nebo ne? Level 2 vypadá takto:
    http://wraith.iglu.cz/python/ukazky/gui.checkbox/check2.png

    6) TCL/TK lze přiznat bonus v tom, že není se třeba explicitně starat o hlavní okno a hlavní kontejner. Ale obávám se, že to na jeho těžkopádnosti nic nemění. Ty léta jsou naa TCL/TK vidět, kdysi to bylo super, GUI aplikace se tehdy dělaly složitě a TCL/TK do toho přineslo jednoduchost a eleganci. Ale časy se mění a moderní dynamické jazyky a toolkity jsou v tomto ještě dál a krom toho podporují i řadu dalších věcí, jako skinovatelnost a podobně.
  • 21. 7. 2005 8:38

    bez přezdívky
    Nandal jste mu to :-) Python je fakt super. Jeste bych trochu zkratil Vas kod:
    checks = []
    checks.append( gtk.CheckButton( label="První" ) )
    checks.append( gtk.CheckButton( label="Druhý" ) )
    checks.append( gtk.CheckButton( label="Třetí" ) )
    checks.append( gtk.CheckButton( label="Čtvrtý" ) )
    checks.append( gtk.CheckButton( label="Pátý" ) )
    
    na
    checks = ["První","Druhý","Třetí","Čtvrtý","Pátý"]
    for popisek in checks:
        checks.append( gtk.CheckButton( label=popisek ) )
    
    No neni ten Python krasnej?
  • 21. 7. 2005 9:32

    bez přezdívky
    Tak ješte jednou, snad už správně :-)
    texty = ("První","Druhý","Třetí","Čtvrtý","Pátý")
    checks = [gtk.CheckButton(label=i) for i in texty]
    
  • 27. 11. 2017 15:24

    PK (neregistrovaný)
    #!/usr/bin/wish
    
    foreach desc {První Druhý Třetí Čtvrtý Pátý} {
        lappend seznam [checkbutton .cb[incr i] -text $desc]
    }
    
    button .tisk -text "Tiskni" -command {tisk $seznam}
    button .konec -text "Konec" -command {exit}
    pack {*}$seznam .tisk .konec
    
    proc tisk {seznam} {
        foreach i $seznam {
            puts "[$i cget -text] [lindex {není je} [expr \$::[$i cget -variable]]] zatržen"
        }
    }
  • 21. 7. 2005 10:20

    Pavel Tišnovský
    1. Ano udělal jsem to jednoduše pro Wish, úprava pro tclsh spočívá pouze v tom, že se vytvoří ono hlavní okno a na začátek se přidá obligátní volání tcshl. Na druhou stranu: co je to spustitelný program? Je to pouze binárka, skript který potřebuje interptreter, dokument s přiřazeným kontejnerem pro zobrazeni? Výhoda Wishe je v tom, že jsem to mohl odladit interaktivně, přidávat a ubírat widgety atd.

    2. V tom jednoduchém řešení to opravdu používá globální proměnnou. Je to z toho důvodu, že se nezjištuje přímo stav dané komponenty (tj. checkboxu/checkbuttonu), ale tato komponenta sama nastavuje specifikovanou či implicitní proměnnou. Ta proměnná buď dá nastavit, nebo je nastavena implicitně (potom má stejný název, jako daný widget). Ve skutečném programu by se proměnná samozřejmě specifikovala, tady je to dost špatně zadaný příklad (i z Tvojí strany), protože v kódu aplikace bych se neměl dotazovat na stav jednotlivých widgetů - osobně jsem to i v programech, kde to nebylo technologicky zapotřebí odděloval (Delphi, C++ Builder).

    3. Co to hlásí za chybu?

    4. Začátečník by určite nepoužíval vložení widgetů do pole/seznamu. Prostě by natvrdo napsal jednotlivé checkboxy a pravděpodobně by explicitně řekl, co se má po každé změně toho checkboxu udělat (například volání metody nějakého objektu, nebo volání funkce ať je to jednodušší). Stejně tak by to udělal prakticky kdokoli při návrhu GUI pomocí nějakého vizuálního nástroje - tam se přece myšoidně naflákají komponenty (widgety a kontejnery) a ke každému se specifikuje funkce/metoda volaná při jejich změně.

    5. Vzhled je samozřejmě závislý na mnoha okolnostech. Dám Ti příklad: oba výše prezentované prográmky spustím na svém pracovním notebooku s Windows XP. Program dělaný v Tcl/Tk se bude chovat jako klasická okenní aplikace (není problém přidat akcelerátory atd.), dokonce se používají přímo prvky Microsoftího GUI. Výsledek: umí to skiny, antialias fontů (pro mě moc důležité při celodením čučení na LCD), fokusy se chovají přesně dle systému atd. Program dělaný v GTK? Zaprvé jsou nějak divně nastavené velikosti fontů (po instalaci GIMPu jsem to musel složitě opravovat), je to prostředí samo pro sebe (tj. neodpovídá ostatním programům v systému) a kam zmizel antialias fontů? Takže je jasné, že co se Tobě líbí na Tvém vytuněném počítači s GTK, nemusí nutně dopadnout dobře na jiném systému a naopak - uznávám však, že Tcl/Tk aplikace na Linuxu bez dalších úprav resourců škaredější než například GTK/Qt s nějakým bitmapovým skinem, alfa kanálem, kulatými rožky oken (IMHO pěkná blbost, co se týče výkonu, a to i na Windows XP) a já nevím co ještě.
  • 21. 7. 2005 12:03

    Petr Mach (neregistrovaný)
    1) Prostě to není kompletní. Spustitelné znamená to, že se to dá spustit třeba z příkazového řádku, že se to vůči uživateli chová jako program.

    2) Děkuji za potvrzení mé doměnky, že správné řešení by nebylo jednoduché a to jednoduché (mě tedy jednoduché nepřijde, viz. to srovnání handlerů), že je nesprávné.

    3)
    invalid command name "tisk"
    invalid command name "tisk"
        while executing
    "tisk $seznam"
        invoked from within
    ".tisk invoke"
        ("uplevel" body line 1)
        invoked from within
    "uplevel #0 [list $w invoke]"
        (procedure "tk::ButtonUp" line 22)
        invoked from within
    "tk::ButtonUp .tisk"
        (command bound to event)
    4) Toto odmítám. Když by začátečník potřeboval pracovat s polem tlačítek, určitě by je vložil do pole, to je vcelku logické. Program neprovádí žádné akce na změnu stavu widgetu, cílem programu je prozkoumat aktuální stav svých widgetů. V každám případě je vidět, že to co je vydáváno za výhodu TCL/TK je Pythonu/GTK vlastní a umí to přehledněji a jednodušeji. Což je to, na co upozorňuji, o nic jiného mi nejde.

    5)
    a) Vzhled GTK aplikací na Windows je nastavitelný pomocí themeselector.exe, jak jsem již uvedl, komu se nelíbí defaultní, může si nastavit třeba téma wimp napodobující windows. Co mám udělat já, aby vaše ukázka vypadala přijatelně?
    b) Kromě toho, mám pocit (třeba podle toho antialiasu fontů), že hovoříte o svých zkušenostech s GTK1, ale to se dnes už nepoužívá, GTK2 je od základu přepracované včetně podpory fontů.
    c) To s tím Gimpem jsem nepochopil, co s tím má společného? Pokud vím, tak Gimp má natvrdo nastaveny vlastní témata, ty systémová ignoruje, nelze podle něj posuzovat standardní GTK. Máte s GTK na windows ještě jiné zkušenosti?
    d) Co se týče antialiasu fontu, tak ten postrádám právě na vaší ukázce.
    e) Můj počítač není vytuněný, je to defaultní instalace Auroxu. Píšu programy v Python/GTK pro Windows, jsem s nimi spokojený a jejich uživatelé, což je nejdůležitější, taky.
    f) Když se podíváte, jaké aplikace a prográmky na windows frčí, tak řada z nich nezapadá do prostředí Windows a odlišuje se (snaži se zaujmout) vzhledem. Nemyslím si, že by to měl být pro někoho problém. Stačí dodržovat kovence správného UI, jako accelerátory a podobně a je to bez problému. Jak jsem předvedl, v GTK to není problém, ani ve Windows ani na Linuxu, vy to v TK asi předvést nedovedete, nebo se pletu?

    6. Jako já opravdu nic nemám proti TCL/TK, ve své době to byla třída. Ostatně, první pokusy s GUI programováním mám právě z TCL/TK. Tehdy nic jiného takového nebylo. Ale včera není dnes. Dnes tu jsou jazyky jako Python, které TCL překonávají (a jsou TCL inspirovány, všechno chytré a užitečné z něj přebraly) i toolkity jako GTK a konkrétně GTK je vyloženě silně inspirován toolkitem TK, ale je modernější a silnější.
  • 21. 7. 2005 12:35

    Petr Cernoch (neregistrovaný)
    Pred chvili jsem poslal delsi odpoved, tentokrat jen k nekolika polozkam:

    add 4)
    Skutecne jste tak naivni ze si myslite ze ZACATECNIK bude hazet komponenty do pole, prochazet je atd? Tento postup, i kdyz je casto logicky, vyzaduje uz pokrocilejsi znalosti daneho jazyka. Zacatecnik to tam proste natvrdo nabastli a je rad ze mu to funguje (coz je ostatne taky to nejdulezitejsi, ze ano?).

    add 5)
    Myslite si ze kazdy bude vedet v cem je dana aplikace delana?
    Kdyz dostanete program, budete jej pouzivat a ocekavat ze se bude chovat podle nastaveni systemu. Je hezke ze je mozne zmenit tema dane aplikace ale zase to vyzaduje specificke znalosti.

    Gtk je jiste uzasna vec a stale se zlepsuje, tomu jiste nikdo neodporuje. Ale toolkitu existuje obecne tolik ze je v nich desny bordel, pritom se vsechny relativne bezne pouzivaji a kazdy vyzaduje jiny styl prace.

    A samozrejme, kazdemu vyhovuje neco jineho -nekomu Qt, nekomu Gtk, nekomu Tcl/Tk atd.

    add 6)
    Ano ve sve dobe to byla trida, ale i dnes je to velmi uzitecny skriptovaci jazyk. Podivejte se jen kolik wrapperu pro jine programy stale pouziva Tk.


    Zaver: stale si myslim ze Tcl/Tk bude "zit" jeste dlouho a je vhodny i pro zacatecniky, hlavne co se "okinkoidnosti" tyce.
  • 21. 7. 2005 14:36

    bez přezdívky
    S bodem 4 vcelku souhlasim. Jsem pokrocilejsi zacatecnik a fakt jsem natvrdo kopiroval radek po radku a byl stastnej, ze to funguje.

    Ovsem jako mirne pokrocily mohu potvrdit, ze Python je pro me naprosto idealni. Pote co jsem ho celkem zvladl, za velkeho krouceni hlavou jsem si precetl knihu o Perlu, abych se zase s nadsenim vrhnul zpet na Python.

    Uprimne receno nechapu kvuli cemu se dnes ucit TCL. Ale ucit se Tk je uzitecne pro pochopeni zakladu, trid, dedicnosti apod. Ty klikaci nastroje pro vytvoreni GUI jsou jiste uzitecne, ale zacatecnik by mel zacit od zakladu - textovy editor a kod u ktereho musi premyslet. Ne jenom si naklikat okynka a pak jen zirat na drat, co ze mi ten RAD nastroj vlastne vytvoril za mastodonta.

    Ano, vzhled je dnes mozna trochu zastaraly, ale to snad neubira programu na funkcnosti, ktera by mela byt na prvnim miste.

    Myslim, ze asi nejlepsi nejaka zlata stredni. Na velmi jednoduche aplikace staci Tk na slozitejsi treba to Gtk nebo Wx.
  • 21. 7. 2005 16:55

    Pavel Tišnovský
    "Pote co jsem ho celkem zvladl, za velkeho krouceni hlavou jsem si precetl knihu o Perlu, abych se zase s nadsenim vrhnul zpet na Python." - tak tohle je naprosto krásná věta, akorát si možná v tomto fóru říkáte o ukamenování :-)))

    Tcl je tak jednoduché, že jeho naučení je prakticky pro každého, co již někdy v imperativních jazycích programoval, otázkou několika hodin. Spolu s nezbytnými knihovnami (řetězce, seznamy, soubory) to zabere dejme tomu jeden pracovní den. Pravda je, že Python je také docela jednoduchý, až na to, že si člověk musí zapamatovat, kam vrazit interpunční znaménka (proč je například za podmínkami dvojtečka, když se její konec pozná z odsazení dalšího řádku?)

    V dalších třech bodech s Vámi souhlasím s tím, že i v Tk jsou vytvořeny velmi složité aplikace (ty většinou komunikují s okolním světem C-programů atd.).
  • 22. 7. 2005 15:40

    Petr Mach (neregistrovaný)
    Tohle zacina uz zavanet fanatismem :-). Python je jednoduchy, tecka. Python se snazi o citelnou syntaxi a dvojtecka tuto citelnost usnadnuje, krom toho prikaz podminky muze byt viceradkovy a jak potom poznat kde konci podminka a kde zacina blok prikazu?
  • 22. 7. 2005 16:59

    Petr Cernoch (neregistrovaný)
    To same se da rict i o vas a vasem krizovem tazeni proti Tcl/Tk :-)))

    Proste proti tomu ze jej spousta lidi povazuje stale za uzitecne, jednoduche a vhodne i pro zacatecniky nic nezmuzete, to je overeny fakt.
    (schvalne, co bude nasledovat jako odpoved?)

    Jinak vsechno je otazkou individuality. Treba mne se perl zda srozumitelnejsi nez python - snazim se jej (python) totiz naucit takze to mam z vlastni zkusenosti. Mozna divne, ale je to tak, lidi jsou ruzni, stejne tak jejich myslenkove vzory atd.


    >> ...jak potom poznat kde konci podminka a kde zacina blok prikazu?

    <hnusna provokace>
    zeby zavorkama jak je to bezne u jinych, normalnich, jazyku? ;-)
    </hnusna provokace>
  • 23. 7. 2005 3:52

    Jakub Hegenbart

    To není provokace, to je velmi rozumné.

    (if <podmínka> <true-forma> <false-forma>)
    (cond (<podmínka> <forma> <forma>*) (<podmínka> <forma> <forma>*)*)

    A je to. Odděluje se na horizonální úrovni mezerami a na vertikální závorkami a je to. Víc člověk vědět nemusí. Indentace je povinnost pro čitelnost, ale ve slušném editoru je automatická. Co by mohl člověk chtít víc?

    Další mnou kdesi výše jmenované jazyky jsou podobně jednoduché. Python jednoduchý není a spousta jiných jazyků je na tom ještě hůř.

  • 23. 7. 2005 9:15

    Petr Mach (neregistrovaný)
    Co chtít víc? Třeba přehlednost? Člověk také třeba navíc musí vědět co jsou ty hvězdičky před uzavírací závorkou a proč jsou jen na druhém řádku nebo proč jsou výrazy uzavřeny do závorky. Nemusíme si asi říkat, že tato forma syntaxe není mezi programátory moc oblíbená, většinově se dává přednost C-like syntaxi.

    Abychom o té přehlednosti, kterou považuji za významnou, nemluvili jen tak do větru, přistupme opět k praktické ukázce. Příklad:

    Máme seznam (pole) výsledků. Jeden výsledek je tříprvkový seznam (pole), kde první a druhý prvek jsou logické hodnoty a třetí hodnota výsledku.
    Naším úkolem je roztřídit tento seznam výseldků na čtyři nové seznamy AB, Ab, aB a ab, kde v AB budou hodnoty vysledku, u nějž byly obě logické hodnoty pravdivé, v ab obě nepravdivé, v Ab pravdivá jen první a v aB pravdivá jen druhá. V Pythonu tento úkol provedeme takto:
    AB = []
    Ab = []
    aB = []
    ab = []
    
    for a, b, hodnota in vysledky:
        if    a and b:      AB.append(hodnota)
        elif  a and not b:  Ab.append(hodnota)
        elif  b and not a:  aB.append(hodnota)
        else:               ab.append(hodnota)
    
    
    Jsem zvědavý na řešení v ostatních jazycích které zde zazněly, především Lispu a TCL. Nechť laskavý čtenář naší disputace sám posoudí, co se mu zdá nebo nezdá být přehledné. Čímž bych také tento spor ukončil, protože se zdá být značně subjektivní.
  • 23. 7. 2005 12:03

    Pavel Křívánek
    Jedno z možných řešení ve Smalltalku je např.:
    resAB := vysledky select: [ :v | v first & v second ] thenCollect: [ :v | v third ].
    resAb := vysledky select: [ :v | v first & v second not ] thenCollect: [ :v | v third ].
    resaB := vysledky select: [ :v | v first not & v second ] thenCollect: [ :v | v third ].
    resab := vysledky select: [ :v | v first not & v second not ] thenCollect: [ :v | v third ].
    nebo třeba
    select := [:val | vysledky select: [ :v | (v first: 2) = val ] thenCollect: [ :v | v third ] ].
    resAB := select value: #(true true).
    resAb := select value: #(true false).
    resaB := select value: #(false true).
    resab := select value: #(false false).
    nebo imperativněji, blíže Vašemu řešení:
    resAB := OrderedCollection new.
    resAb := OrderedCollection new.
    resaB := OrderedCollection new.
    resab := OrderedCollection new.
    
    vysledky do: [ :v |
        (v first & v second) ifTrue: [ resAB add: v third ].
        (v first & v second not) ifTrue: [ resAb add: v third ].
        (v first not & v second) ifTrue: [ resaB add: v third ].
        (v first not & v second not) ifTrue: [ resab add: v third ] ].
    Příkladů, na kterých se dá ukázat, že právě ten a ten určitý jazyk je nejlepší, se dá vymyslet hodně. Podobně by se dalo třeba zadat naimplementovat tak základní věc, jako singleton (jedináček), nebo nějaký příklad, kde se dá skvěle využít dynamická dědičnost, a Python by proti Selfu vypadal jak malej do školky (což by, mimochodem, nebyl zcela mylný závěr ;-).
  • 24. 7. 2005 8:07

    Petr Mach (neregistrovaný)
    No, nevím jestli jsme si rozuměli, mě šlo o nejsrozumitelnější formu řešení, ne nejkratší, nejhutnější a podobně. Které z těch svých řešení považujete za nesrozumitelnější? Na oplátku za vaše alternativy vám také předvedu Pythoní alternativu, která začátečníkům už tak srozumitelná připadat nebude, ale vy ji možná oceníte.

    AB = [c for a, b, c in vysledky if a and b]
    Ab = [c for a, b, c in vysledky if a and not b]
    aB = [c for a, b, c in vysledky if b and not a]
    ab = [c for a, b, c in vysledky if not a and not b]
    
    Hezké, že? Předvede se někdo s TCL prosím?
  • 24. 7. 2005 10:17

    anonymní
    Ano, pochopil jsem, že Vám jde o čitelnost (což minimálně na druhém řešení určitě vidět není ;-). Formálně nejsrozumitelnější by mělo být první řešení, protože popisuje spíš získaná data a ne způsob, jak je získat.

    Nemyslím si, že podobná srovnání by měla význam a je těžké najít objektivní zadání. Tak bychom se mohli donekonečna přetahovat třeba na úkolech, jak zjistit datum odedneška za týden (Date today + 7 days) apod. Už jsem viděl třeba srovnání programovacích jazyků, jejichž úkolem bylo zpracovat XML soubor, které bylo uděláno tak, aby s přehledem vyhrálo PHP.

    Naráží tady na sebe dvě naprosto odlišné koncepce při genezi programovacích jazyků. Python na sebe nabaluje postupně nové a nové vlastnosti a čerpá při tom z mnohota i nepříbuzných zdrojů. Naproti tomu jazyky jako Lisp, Self a Smalltalk se snaží dosáhnout maximální jednoduchosti s vědomím, že jednoduchost je matka komplexnosti.

    Například jmenovaný Self je přímý potomek Smalltalku. Doplnil jej o násobnou dědičnost, mixins, dynamickou dědičnost, vylepšené jmenné prostory apod. A dosáhl toho, věřte nebo ne, jeho ZJEDODUŠENÍM. A to i bez toho, aby mu cokoliv ubral z jeho vyjadřovacích schopností. Je mnohem těžší skutečně důkladně analyzovat problémy stávajícího jazyka než prostě přidat pár dalších hezkých pravidel do gramatiky. Správná cesta vývoje programovacích jazyků vede směrem k Lispu.

    Celkem chápu, že ve Vás smalltalkovský rozsypaný čaj respekt rozhodně nevyvolává. Můžete si ho ale upravit dle libosti, třeba takhle (skutečný funkční příklad):
    výsledkyAB := UspořádanáKolekce nová.
    výsledkyAb:= UspořádanáKolekce nová.
    výsledkyaB := UspořádanáKolekce nová.
    výsledkyab := UspořádanáKolekce nová.
    
    výsledky zpracuj: [ :výsledek |
    	(výsledek první a: výsledek druhý) kdyžJePravda: [ výsledkyAB přidej: výsledek třetí ].
    	(výsledek první a: výsledek druhý ne) kdyžJePravda: [ výsledkyAb přidej: výsledek třetí  ].
    	(výsledek první ne a: výsledek druhý) kdyžJePravda: [ výsledkyaB přidej: výsledek třetí ].
    	(výsledek první ne a: výsledek druhý ne) kdyžJePravda: [ výsledkyab přidej:výsledek třetí  ] ].
    Můžete si to porovnat s předchozím příkladem a vydedukovat, co je ve Smalltalku dáno syntaxí jazyka a co je prachobyčejné volání zpráv, které si můžete modifikovat a dotvářet jak se Vám zlíbí :-)
  • 25. 7. 2005 9:46

    Pavel Tišnovský

    V TCL například takto (osobně bych to napsal trošku jinak, ale nebylo by to tak čitelné):

    
    set AB {}
    set Ab {}
    set aB {}
    set ab {}
    set vysledky { { 0 0 prvni} { 0 1 druhy} { 1 0 treti} {1 1 ctvrty}}
    
    foreach i $vysledky {
        set podminka1 [lindex $i 0]
        set podminka2 [lindex $i 1]
        set vysledek [lindex $i 2]
        if       [expr $podminka1 & $podminka2] {
            lappend AB $vysledek
        } elseif [expr $podminka1 & ! $podminka2] {
            lappend Ab $vysledek
        } elseif [expr ! $podminka1 & $podminka2] {
            lappend aB $vysledek
        } else { lappend ab $vysledek}
    }
    puts $AB
    puts $Ab
    puts $aB
    puts $ab
    
    

    Podle mě trošičku lepší řešení, kde se pořád neopakuje stejná operace:

    
    set AB {}
    set Ab {}
    set aB {}
    set ab {}
    set vysledky { { 0 0 prvni} { 0 1 druhy} { 1 0 treti} {1 1 ctvrty}}
    
    foreach i $vysledky {
        set podminka1 [lindex $i 0]
        set podminka2 [lindex $i 1]
        set vysledek [lindex $i 2]
        if       [expr $podminka1 & $podminka2] {
            set seznam AB
        } elseif [expr $podminka1 & ! $podminka2] {
            set seznam Ab
        } elseif [expr ! $podminka1 & $podminka2] {
            set seznam aB
        } else {
            set seznam ab
        }
        lappend $seznam $vysledek
    }
    
    puts $AB
    puts $Ab
    puts $aB
    puts $ab
    
    
  • 23. 7. 2005 22:09

    Jakub Hegenbart

    Vážený pane, před uzavírací závorkou nejsou žádné hvězdičky. Najděte si v nějakém slovníku výpočetní techniky slovo „metaznak“.

    Hvězdičky jsou na místech, kde se prvek před nimi může vyskytnout alespoň jednou nebo se nemusí vyskytnout vůbec. Alternativa by byla místo <forma> <forma>* napsat jen <forma>+, ale zjevně by to byla marná snaha, pokud Vám unikla konvence hvězdičky, asi byste těžko pochopil plus. A já myslel, že tenhle (pravda, mírně neformální, ale celkem běžný) zápis budou znát všichni. Narážím na něj dnes a denně a regulární výrazy se taky snad běžně používají.

    Není co chápat na tom, proč jsou jen na druhém řádku. Jako kdybyste říkal, že při čtení syntaxe Cčka (aby se ji naučil) musí člověk předem vědět, proč se kde v Cčku píší jaké závorky a kam který prvek jazyka. Omyl! Zápis syntaxe je tu právě od toho, aby mu řekl, kam má co psát.

    Pokud nedokážete pochopit (k této domněnce mne vede zjevná nesouvislost vaší odpovědi a mého příspěvku, nebo přinejmenším souvislost neviditelná pro mne) ani takhle triviální zápis dvou nezávislých syntaktických konstrukcí (příklad formy if a příklad formy cond), jsem zvědavý, jak byste se tvářil na BNF zápis, který do toho zamíchá třeba ještě rekurzi.

  • 24. 7. 2005 7:47

    Petr Mach (neregistrovaný)
    Vážený pane, hvezdička je hvězdička, ať jí říkáte jak chcete. Má-li význam metaznaku dle pravidel regulárních výrazů, je to nutno uvést, protože formálních zápisů existuje řada já vaši ukázku pochopil tak, že to je součást syntaxe (L(i(s(p(u))))) :-). Jednu radu do budoucna, jestli vás příště někdo nepochopí, zeptejte se nejdřív sám sebe, co jste udělal špatně, že jste zůstal nepochopen, je to lepší, než obviňování všech okolo, že jsou hlupáci, co vás nechápou :-). S BNF notací problém nemám, její upravenou verzi používá např. referenční příručka jazyka Python: http://python.org/doc/2.4.1/ref/notation.html
  • 24. 7. 2005 4:43

    Jakub Hegenbart
    BTW mně to vychází nějak takhle:
    (let (|ab| |aB| |Ab| |AB|)
        (loop for (a b c) in results
            if a 
                if b
                    collect c into |AB|
                    else collect c into |Ab|
                else 
                if b
                    collect c into |aB|
                    else collect c into |ab|
            finally (return (values |ab| |aB| |Ab| |AB|))))
    Ale určitě by to šlo i líp, já jsem začátečník... :-) Tohle je imperativní ekvivalent, zamyslím se nad čistším řešením. Ale tohle by mělo být čitelné i pro nelispera... ;-)
  • 24. 7. 2005 7:52

    Petr Mach (neregistrovaný)
    Nad čistším řešením se zamyslete, jinak by to vypadalo, že se stydíte za Lisp v jeho čisté podobě a snažíte se v něm emulovat imperativni jazyky a to můžeme použít rovnou je, že? Ale všechna čest, na to že to je lisp je to docela čitelný :-). Nicméně dle vaší poslední poznámky se asi zhodneme, že lisp není zrovna králem, co se čitelnosti týče.
  • 24. 7. 2005 12:42

    Jakub Hegenbart
    Já se za něj nestydím, jde spíš o to, že těch přístupů, jak tohle řešit může být hromada. Navíc v závislosti na zbytku kódu může být více nebo méně jednoduchá.

    Tady jsem použil LOOP makro, který je názorným příkladem toho, že spousta problémů se v LISPu dá řešit tak, že se nad ním vytvoří doménově specifický jazyk. (Zde třeba jazyk k popisu iterativních algoritmů - zde jsou nějaké příklady: http://www.gigamonkeys.com/book/loop-for-black-belts.html . Opravdu doporučuju přečíst, LOOP umí neskutečné věci. ;-))

    Takže on to není zase až tak "čistý LISP", jak by mohl být: Nejlispovější přístup by bylo asi použití funkcí vyššího řádu. Důležité je, že Lisp se dle mých dosavadních zkušeností ze všech jazyků nejméně brání použití přístupu, který není v daném jazyku zcela přirozený. (Cynik by asi řekl, že v Lispu se ve všech programovacích paradigmatech programuje stejně špatně. ;-)) Python ale v tomhle směru taky docela boduje, to uznávám. :-)

    Kromě toho, chtělo by to nějaký větší příklad, tak 10x-20x, na takových pidipříkladech se člověk moc o ničem nepřesvědčí. Znáte tuhle studii?

    http://www.flownet.com/gat/papers/lisp-java.pdf

    Je škoda, že do ní nepřidali Python. Bylo by to hezké srovnání...

    Promyslím si jiná řešení, ale jsem teď dost vytížený prací, takže mi možná pár dní potrvá.
  • 25. 7. 2005 8:21

    Petr Mach (neregistrovaný)
    No, takže jestli tomu rozumím, tak napsat tento vskutku jednoduchý příklad správně po lispovsku, aby se projevila jeho síla, je tak komplikované, že na to nemáte čas. Ale mě to moc nepřekvapuje, protože na téhle úrovni si Lisp dovedu představit. Proto také nesouhlasím s tvrzením, že Lisp je jednoduchý jazyk, není. Jednoduchý jazyk je Python. Lisp má možná jednoduchou syntaxi a pravidla, ale jazyk je to složitý a programovat v něm je náročné. Čuchnul jsem si k tomu skrze Scheme, když jsem se snažil psát si pluginy pro Gimp. Ono když se to vezme kolem a kolem, tak assembler je taky jednoduchý jazyk, akorát to rprogramování v něm je poněkud dřina, něco jako okopávat obrovské pole jednoduchou motyčkou.

    Co se týče té studie, tak je poněkud zastaralá, nevím jak Lisp, ale Java od té doby urazila značnou cestu. Vyvíji se takto i Lisp? V každém případě by Python vykazoval v některých ohledech nižší výkon.

    Co se týče většího příkladu, to je problém, protože i tak jednoduchý přiíklad nebyl nikdo ochoten implementovat v TCL. Ale podívejte se na U++ thread v této diskuzi, za chvíli tam dám řešení jednoho příkladu v Pythonu.
  • 25. 7. 2005 12:07

    Pavel Tišnovský
    Já se teď nechci pouštět do obsáhlých diskuzí ohledně Lisp vs. Java, ale zajímalo by mě, jakou "značnou cestu" od té doby Java urazila. Pravda, vylepšila (zrychlila) se JVM díky technologii hot-spot a do jazyka byly přidány dvě-tři nové konstrukce pro vylepšení for-cyklů (prakticky jde o slabou náhradu za "foreach", "map" a "apply"). Ale to je tak vše, tj. mohl se změnit tak jeden ze tří prvků zmíněných v tom článku.

    Porovnání Javy a Lispu by muselo být provedeno z více - i implementačních - hledisek (sám teď v práci Javu a Lisp dost intenzivně používám a nejde o jazyky vzájemně zaměnitelné).

    Možná Tě Scheme (což je očesaný Lisp pro akademiky :-))) zklamalo právě díky GIMPu. Lispy jsou dobré pro práci s databázemi, seznamy, grafovými strukturami atd. Při skriptování programů jejich krása a elegantnost tak nevynikne, i když se zde často používají (GIMP, Emacs, v budoucnu snad i Vim ...).

    Nezkoušel jsi náhodou Guile? Doporučuji alespoň na chvíli zkusit, spolupracuje s GTK, takže GUI jak má být.
  • 25. 7. 2005 17:07

    Petr Mach (neregistrovaný)
    Java zrychlila nejen kvůli hot-spotu, ale řadě dalších optimalizací. Přitom ta studie porovnává právě toto, pravda, ne jenom toto. Java 1.2 je prostě stará a studie starých věcí mi přijdou nezajímavé. Je to studie něčeho co někdy, konkrétně rok 1999, bylo a to je v IT děsně dlouhá doba. Ale nedostal jsem odpověď na otázku, jestli je Lisp živý jazyk, který se vyvíjí, nebo ne.

    Ad scheme. Možná, že je to kvůli Gimpu, pro který to není vhodný a na kterém nevyniknou výhody, a tak vyniknou nevýhody. Ale pak o Lispu nelze hovořit jako o univerzálním jazyku (to podle mě není možné o žádném jazyku). Naštěstí od Gimpu 2.0 je tento možno skriptovat i v Pythonu, to samé platí i o Vimu.

    Já jsem zkusil hodně jazyků, protože jsem dlouho hledal ten pravý jazyk pro mě:
    Jazyk v kterém se elegantně snadno a rychle programují menší i větší věci (několikařádkové skripty i aplikace v rozhahu až desítek tisíců řádků).
    Jazyk který mi snadno umožní psát multiplatformní aplikace běžící na linuxu i ve Windows.
    Jazyk který pokrývá řadu oblastí, které mě zajímají (systémové skripty, GUI aplikace, webové aplikace, síťové a multithreadové aplikace typu klient-server) a který mě hned tak nevyšplouchne ani když mě začne zajímat něco jiného (dobrá podpora, bohaté knihovny).

    Najít takový jazyk nebylo jednoduché, hledal jsem ho několik let, ale nakonec jsem ho našel v Pythonu. Python je pro mě jazyk, v kterém je zábava programovat. A Python je skvělý, možná až moc. Nechci tvrdit že je to univerzální jazyk, ale je to jazyk který pokrývá tak širokou oblast, že jsem prakticky přestal používat na skriptování bash a na aplikace C. Jediné omezení které jsem ohledně Pythonu pocítil je jeho výkon a to pouze v jednom případě, kdy jsem potřeboval zpracovat miliony denně naměřených hodnot (dbf velký cca 6 MB) v statistické a průběhové grafy. Denní výsledky se počítají cca 20 s, týdenní cca 60. Uvažoval jsem, že to přepíšu v něčem rychlejším, nebo že si pro Python napíšu knihovnu pro výpočty v C. Ale když jsem zjistil, že ten dbf soubor se v programu napsaném v C++ generuje cca 12 s (pouze převod z binárního souboru na dbf), tak jsem naznal, že se to asi stejně nevyplatí.

    Takže v Pythonu jsem našel jazyk, který je pro mě univerzální a v kterém je radost programovat. A to že se používá občas i jako skriptovací jazyk aplikací jako např. Gimp, Blender, OpenOffice.org (jak to funguje doporučuju podívat se např. na http://klub.openoffice.cz/node/view/793/907) - to je už jen třešnička na dortu a dobré zúročení investice do naučení se Pythonu. Dále mohu ještě upozornit na implementace Pythonu pro jeho použití v prostředí Java (Jython) a .NET (IronPython - ve vývoji), dále dobrá podpora Windows a možnost psaní COM Serverů i klientů, tedy např. používat obj. model Excelu v Pythoním programu a podobně. Jeho možnosti jsou vskutku široké. K dokonalosti mi chybí možnost používat Python ve web browserech jako IE nebo Mozilla na místo Javascriptu, ale i s tím se laškuje.

    Co tím chci říct. Python znám relativně dlouho a stále oběvuji jeho nové a nové možnosti. Jsem s ním plně spokojen, takže zkoušet další jazyky nemám potřebu. Až mi bude něco chybět, podívám se, který jazyk mi to poskytne.
  • 25. 7. 2005 20:06

    Petr Mach (neregistrovaný)
    Hmm, root mi nějak neuložil odpověď nebo co, taková dlouhá byla, zkusím odpovědět znovu, lépe a radostněji.

    =======================================================================

    No, Java se optimalizuje a zrychluje jako taková nejen díky hot-spotu. Do jazyka toho bylo přidáno mnohem víc. Např. zde http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html se můžete podívat na novinky mezi verzemi 1.4 a 1.5. Studie se týká verze 1.2 a je tedy poplatná době svého vzniku, což je rok 1999, v IT je to prehistorická doba.

    Scheme mě zklamalo svou kriptičností a nepřehledností a to se bude projevovat i při práci s databázemi, seznamy atd. Krom toho tu někde zazněla myšlenka, že Lisp je univerzální jazyk, ne? Tak by mělo být jedno, co v tom dělám. Já nechci mít jeden jazyk na databáze a jeden na GUI, protože co když budu chtít udělat program který pracuje s databází a má i GUI. Já chci jazyk, který mi pokryje co největší spektrum mých potřeb.

    Ne, Guile jsem nezkoušel, vždyť to je to samé v bledě modrém jako Scheme, potažmo Lisp. A především, já už nemám potřebu zkoušet a zkoumat vůbec žádné jazyky. Vyzkoušel jsem jich hodně, než jsem našel ten pravý - Python a teď zkoumám možnosti Pythonu, a že je co ke zkoumání. Teprve kdybych narazil na problém, který by Python neuměl (dostatečně efektivně) řešit, podíval bych se po dalším jazyku, který by mi pomohl.

    Chvíli to trvalo, než jsem si našel jazyk vyšší úrovně, který mi vyhovoval. Měl jsem na něj velké nároky. Třeba někomu v rozhodování pomůže, když zde objasním, proč preferuji právě Python. Od jazyku co jsem hledal jsem chtěl:

    1) Aby se v něm snadno a efektivně programovalo (to je asi základní požadavek na všechny jazyky vyšší úrovně, měla by to být jejich nejvyšší deviza).
    2) Daly se v něm snadno psát multiplatformní programy běžící v Linuxu a Windows.
    3) Byl vhodný na psaní malých (pár řádkové skripty) i větších (řádově tisíce řádků) programů.
    4) Pokrýval mé potřeby - systémové skripty, GUI aplikace, webové aplikace, multithreadové síťové aplikace klient/server - a pokud možno mě nenechal ve štychu, když se objeví i jiné požadavky.
    5) Měl bohaté knihovny.

    Z počátku jsem se Pythonu vyhýbal, také jsem měl předsudky vůči povinnému odsazování, konec konců, byl jsem Céčkař. Krom toho měl Python i jiné nedostaky, jenž jsem kritizoval, ale protože jsem stále nemohl nic uspokojivého najít, zkoumal jsem i Python. Na Pythonu se intenzivně pracuje a neustále se vylepšuje, od verze 2.2, která odstranila řadu nedostatků, se stal pro mě plně použitelným. Po dlouhodobějším používání jsem i pochopil jak je výhodné strukturování programu odsazováním, a že to je dobrá vlastnost, která dělá Python silnějším. Ale chtělo to vlastní zkušenosti, takže si nemyslím, že bych o tom přesvědčil nějakého zdejšího odpůrce. Ale i tehdy, kdy se mi to také nelíbílo, jsem to považoval za malou daň, kterou člověk musí zaplatit za ostatní silné stránky Pythonu.

    Python má ale i další vlastnosti, které jsem po něm nepožadoval a kvůli kterým stojí za to. Používá se jako skriptovací jazyk některých aplikací jako Gimp, Blender nebo OpenOffice.org (ukázka: http://klub.openoffice.cz/node/view/793/907) čímž se zúročí investice do jeho naučení se. Má dobrou podporu Windows, lze v něm např. snadno psát COM Servery i klienty, takže např. lze v pythoním programu snadno používat Excel:
    import win32com.client
    exc=win32com.client.Dispatch("Excel.Application")
    exc.Visible = 1
    exc.Workbooks.Add()
    exc.Cells(1,1).Value = "Hello"
    
    Tohle je funkční ukázka vytvoření XLS souboru kde v buňce A1 je nápis Hello. Díky nastavení Visible = 1 se všechny příkazy zobrazují online. Je to snadné, stačí se "jen" naučit objektový model Excelu, Wordu a dalších COM serverů, jenž lze ve windows nalézt. Takže moje pozornost není zaměřená na další a další jazyky jako Guile. V jazyku mám jasno a teď zkoumám jeho různá využití. U Pythonu je vskutku co objevovat.

    Python je dobrý jazyk, možná až moc. Nedovolím si tvrdit, že to je univerzální jazyk, protože to není žádný, ale pro mé potřeby se univerzálním jazykem stal. Původně jsem hledal nějaký jazyk vyšší úrovně jako doplněk pro jazyk C, který jsem používal. Python je ale tak dobrý, že jsem C úplně přestal používat, zcela mi ho nahradil, stejně jako Bash. Zatím mi nenahradil PHP, ale to jen proto, že není tak rozšířený a obecně dostupný na serverech poskytující web hosting. Takže když někomu něco dělám, musím se přizpůsobit tomu, co tam má, bohužel. Rád bych, kdyby mi nahradil i JavaScript, to asi nehrozí i když i na tom se pracuje. Bylo by fajn moci aspoň programovat na Mozilla platformě v Pythonu, binding existuje, ale zatím není standardní součástí Mozilly.

    Někoho by mohlo zaujmout i to, že Python je implementovaný pro prostředí Java (Jython) a .NET (IronPython - ve vývoji). Python je moderní silný jazyk s širokými možnostmi a přitom snadno naučitelný a pochopitelný. Myslím že stojí přinejmenším za pozornost a imho nikdo nebude litovat toho, když se naučí v něm programovat, není to těžké. Imho toho nabízí řádově víc, než třeba právě TCL.

    Jediné omezení, které jsem s Pythonem zatím pocítil je výkon, přeci jen to je interpretovaný a ne překládaný jazyk. Ale lze si pomoci knihovnou psyco, která bez práce (za cenu trochu větších paměťových nároků) programy v Pythonu docela urychluje. Psal jsem např. program, který zpracovává miliony naměřených údajů do statistických a průběhových grafů. Naměřená data se nachází v cca 6 MB velkých dbf souborech. S pomocí psyco jsem dosáhl rychlost zpracování denního měření (jednoho dbf souboru) za cca 20 sekund, týdenní (sedm dbf souborů) za cca 60 sekund. Přitom program v C++, který konvertuje binárně uložená data do toho dbf jeden dbf soubor generuje cca 12 sekund.

    A vždy je možno výpočetně náročné funkce napsat v C a v Pythonu je pak používat jako knihovnu. Tako fungují třeba GUI knihovny a podobně. Pořád je to jednodušší a rychlejší, než psát celý program v C.
  • 26. 7. 2005 8:50

    Pavel Tišnovský
    Ano, pro toho, kdo LISP či Scheme nepoužívá častěji, se jedná o poněkud zvláštní jazyk, minimálně počtem závorek (ty však mají pevně daný a jediný význam). Ale při správném odsazování se určitě nejedná o nepřehledný jazyk. Práce s databázemi a seznamy je opravdu v LISPových jazycích jednoduchá, protože se zde využívají vlastně základní konstrukce jazyka (samotný program je uložen v seznamu). A LISPové jazyky se samozřejmě vyvíjí, sice ne tak rychle, jako při vzniku CLOS, ale přece jen (například různé embedded LISPy). Také podpora pro paralelní programování je v LISPu nejpropracovanější, pravda však je, že tuto možnost moc lidí nevyužije. Ještě se zmíním o Tvém názoru na Python (nejsem v žádném případě jeho odpůrce, ale také má nějaké chyby). Opravdu Ti závidím (to myslím bez urážky), také bych chtěl používat jeden programovací jazyk pro všechny mé programy (tj. jak v zaměstnání, tak i na soukromé testíky a "jednorázové" programovací akce atd.). Výběr je však ztížen více okolnostmi. Zaprvé se při týmové práci musí vybrat jazyk, u kterého je zřejmé, že se vyplatí na něj dělat školení (tady u nás vyhrála Java a částečně C) a že nějakou dobu vydrží stabilní (to u Javy myslím také platí pokud to Sun přežije, u C to už platí dokonale – všechny stabilní a odladěné věci mám napsané v C). Další problém, a to pro moji práci závažnější, je ten, že žádný jazyk není úplně univerzální (ostatně to také zmiňuješ). Například pro embedded systémy se používá něco úplně jiného, než pro intranet a skriptování. Python opravdu obsáhne značnou část programování a je integrován do několika programů, ale co zbytek světa? Například v AutoCADu musím (a chci) používat AutoLISP – nic lepšího si zde nedovedu představit, pro low-level grafiku C, pro návrh GUI TCL :-o atd. A to se nezmiňuji o intranetových aplikacích (máme v práci rozjeté tři) – ty jsou řešeny v JSP/Javě. Mimochodem - výstup do DOCu, XLS a PDF je možný díky projektům POI a FOP (viz můj seriálek na Rootu - http://www.root.cz/serialy/formatovane-dokumenty-a-tiskove-sestavy-v-jave/), a to bez nutnosti mít nainstalované Microsoft Office či OpenOffice (uznávám, že to je trošku OT, ale když už se bavíme o knihovnách...). Díky tomu, že žádný ze zmíněných jazyků není úplně universální, musím mezi nimi "poletovat" (i vícekrát za den) a i z toho důvodu se mi nechce učit další syntaxi, která je IMHO dost odlišná od zavedeného dua Java/C. Pokud však máš takovou práci, kde Ti vystačí Python, tak Ti opravdu závidím, můžeš se tak zdokonalovat v jedné věci, což se mě, díky velkému "rozptylu" určitě tak nedaří (jasně, C znám dokonale, ale o Javě si to po přečtení jedné knihy už nemyslím :-( K tomu DBF - zrovinka teď něco podobného řeším v práci. Jde o zpracování dvou DBF souborů, každý o velikosti cca 14MB. V Oracle se vzájemné provázání a porovnání provádí cca hodinu, tak to přepisuji do C-čka. Načtení je hotové za pár sekund, musíš si jenom uvědomit, že DBF mají pevnou délku záznamu, takže se to dá načíst jedním readem. Jestli existuje nějaká knihovna pro práci s DBF, která to také umí, nevím, ale k těmto knihovnám mám trošku odpor, raději jsem si to napsal sám. Pokud chceš znát strukturu souboru DBF, rád Ti ji pošlu. Osobně bych si s tím však hlavu nedělal, 60 sekund není žádný hrozný čas. To blokování serveru s Oracle na celou hodinu je větší problém :-) S tím, že je dnes v mnoha případech chyba psát celý program v C, naprosto souhlasím, většinou je to mrhání programátorského času.
  • 26. 7. 2005 16:36

    Petr Mach (neregistrovaný)
    Jazyk který místo:
    x = (a+b) / (c-d)
    y.attr = z
    
    používá:
    (setf x (/ (+ a b) (- c d)))
    (setf (attr y) z)
    
    skutečně nemohu považovat za přehledný. Tok programu totiž odporuje přirozenému (či ve škole naučenému, viz matematika, fyzika) myšlení. To nespravíte ani odsazováním a navíc tak máte jak náročné odsazování tak miliony nepřehledných (protože do sebe x krát vnořených) závorek. Vím co to znamená hledat zapomenutou závorku v Céčku, fakt bych to nechtěl dělat v Lispu :-).

    Nepoužívám jen jeden programovací jazyk. Používám aktivně ještě PHP (protože historické důvody a webhosting (i když mod_python existuje)) a JavaScript (protože prohlížeče). Ale nahradil mi Céčko, bash, awk, sed (a podobné utility příkazového řádku) a Javu. Plus všechny ostatní jazyky vyšší úrovně, které jsem zkoušel (jako Perl, Ruby, TCL) které nejsou tak dobré.

    IMHO syntaxe Pythonu není zas až tak vzdálená od dua C/Java. Ne v porovnání s jazyky jako Lisp, Pascal, VB nebo Ruby. Mně kolečko Python, JavaScript, PHP potíže nečiní, všechno to jsou jazyky s C like syntaxí. Na to odsazování si člověk rychle zvykne, beztak ho pořád používá.

    Já strukturu DBF souboru znám, ostatně, pracuji s nimi taky přímo. Ale načtení jeho obsahu do paměti jednim vrzem mi nepomůže, protože čtení je stejně kešované a především, všechny ty hodnoty jsou řetězce která musím převést na čísla abych s nimi mohl pracovat, to je největší příčina zdržení při načítání. Těch 60 sekund ale není jen načítání dbf, jestli jste to tak pochopil. V těch 60 sekundách je načítání 7x dbf, celkem tedy asi 40 MB dat + jejich zpracování a vytvoření grafů. Výsledek vypadá nějak takto http://wraith.iglu.cz/python/ukazky/img.uhliky/uhliky.png (tohle je výsledek z ranné vývojové verze). Vzhledem k tomu, že týdenní přehled se dělá jednou za týden, tak těch 60 sekund není skutečně mnoho. Nevím na kolik bych to urychlil použitím Céčka, ale vím, že bych to psal mnohem a mnohem delší dobu, a že to za to nestojí, i kdyby to pak běželo jen vteřinu, což je nereálné. Ale mám tak nějak pocit, že v tom zapadlo, že tohoto pěkného času jsem dosáhl díky knihovně Psyco, která Python docela pěkně zrychluje (tedy případ od případu, dá se říct, že urychlení je přímo úměrné poměrné velikosti kódu v pythonu, tj. když pythoní program bude většinu času trávi v céčkovských knihovnách, tak to psyco moc neurychlí, ale to už zase poběží skoro stejně rychle jako program napsaný v céčku) a přitom se to až překvapivě prostě používá.
  • 26. 7. 2005 17:09

    Jakub Hegenbart

    "Tok programu totiž odporuje přirozenému (či ve škole naučenému, viz matematika, fyzika) myšlení."

    Přirozené? Odkdy je na středověkém algebraickém zápisu něco "přirozeného"? To, že se z nějakého důvodu ujal? (A podotýkám, že vznikl v prostředí mnohem jednodušších jím zapisovaných problémů. Dnes máme trošku jinou dobu.)

    "To nespravíte ani odsazováním a navíc tak máte jak náročné odsazování tak miliony nepřehledných (protože do sebe x krát vnořených) závorek. Vím co to znamená hledat zapomenutou závorku v Céčku, fakt bych to nechtěl dělat v Lispu :-). "

    Nevím jak Vy, ale za mě všechny tyhle věci dělá editor, a to nejen v Lispu.

  • 27. 7. 2005 16:55

    Pavel Tišnovský
    A co je ještě horší: infixová notace je plná záludností, někdy se totiž, zejména pro unární operátory, používá notace prefixová, někdy postfixová (viz například sin 40, n! apod.). V tom aby se pr@se vyznalo :-) A i když se s ní smíříme (nic jiného nám, zdá se, v mnoha jazycích nezbývá), tak si všimněme, že ne všechny programy a přístroje jednou danou infixovou notaci používají dokonale. Například většina programů typu "Kalkulačka":

    Chci vypočítat sinus 45 stupňů. Normálně se to přece zapisuje sin 45, tak to tak namačkám a výsledek: nejdříve se vypočítá sinus předchozího výsledku na displeji (tj. většinou nuly) a potom se tam v celé kráse zobrazí 45 :-) A to neberu složitější vzorce s mnoha binárními operátory, kdy mnoho "Kalkulaček" má omezený počet registrů a tím pádem i omezenou možnost správného vyhodnocení priority (což je další věc, která mi na infixové notaci strašně vadí a ani Python toto nijak nespraví :-).

    No, najít zapomenutou závorku v C-čku dělá mnohem menší problémy než úprava zdrojáku v Pythonu, když je polovina odsazená pomocí TABů a druhá polovina pomocí mezer :-) [první zkušenosti s Makefily mě opravdu poučily].
  • 5. 8. 2005 20:13

    Petr Mach (neregistrovaný)
    Mluvíte ještě o programovacích jazycích nebo o kalkulačkách? :-) Nehledě na to, že nesouhlasím, na normální kalkulačce uděláte výpočet a s výsledkem můžete hned pracovat dál. U prefixové notace máte smůlu, tam musíte operátor uvést předem.

    Normálane se sinus zapisuje jako sin(45) nebo math.sin(45), s operátory to nemá nic společného.

    Na vyhodnocování priorit se odjakživa používají závorky, v tomto případě je používá i Python, o LISPu ani nemluvě :-)).

    Jo, ona úrava zdrojáku v C, kde jsou náhodně prohozeny velká a malá písmena taky není snadná. Jak jste sám prohlásil, nemáte s tím zkušenosti, já jsem toho v Pythonu napsal už spoustu a vím že jde jen o teoretické strašení, v praxi s tím potíže nejsou.
  • 8. 8. 2005 8:53

    Pavel Tišnovský
    Já jsem se bavil o postfixových kalkulačkách (doufám, že jsem to v některém předešlém příspěvku nespletl), takže operátor je na zobrazený výsledek vždy aplikovatelný.

    Taky jsem ještě na průmyslovce na tabuli napsal cos(blablabla) a hned jsem si šel sednout:-( Paní profesorka do programování viděla, ale tento zápis opravdu v matematice nechtěla vidět, tam se dělají závorky jen tehdy, když už není zbytí.

    Jak se s využitím školních znalostí napíše v nějakém programovacím jazyce běžný výraz s čísly a proměnnými, který obsahuje pouze operace násobení, sečítání, odečítání a dělení? (teď se raději vůbec nebavím o přiřazení vs. rovnosti, v tom je zmatek největší). A jak se to dá rozšířit na funkce?

    Priority nejsou v postfixovém zápisu zapotřebí (viz můj seriál o Forthu tady na Rootu). Takové věci jako závorky jsou zapotřebí POUZE u infixu. To, že se používají v Lispu, má jiný důvod, například funkce + sečítá libovolný počet svých parametrů.

    Prohození velkých a malých písmen při normální editaci snad nehrozí? Ale sám se setkávám i se svými staršími kódy, kde je normálně polovina zdrojáku psaná s TABy a polovina s mezerami (podle toho, z jakého kontextu jsem spouštěl staré dobré BC, které neumělo něco jako :retab).
  • 28. 7. 2005 0:42

    Petr Mach (neregistrovaný)
    Od te doby, co existuje povinna skolni dochazka. At se vam to libi nebo ne, toto je zavedeny zapis.

    Jo, to uzivatele VB rikaji taky, akorat mluvi o IDE, ktere dela vsechno za ne, to neni znamka kvality jazyku.
  • 28. 7. 2005 0:58

    Jakub Hegenbart
    To je zápis na papíře. No a? Léta jsem pracoval s RPN kalkulačkou, než jsem ji nešťastně ztratil. Do té doby jsem si kalkulačkoval jako prase v žitě. Teď trpím „intiuitivním (™) algebraickým (®) zápisem“ :-) Už se nemůžu dočkat HP-49G+, brousím si na ní zuby :-)
  • 30. 7. 2005 14:12

    Petr Mach (neregistrovaný)
    Vždycky se najde nějaká ta 4% menšina co to má ráda jinak a nic proti ní, to však nemění nic na tom, že mainstream a zavedený způsob, který vyhovuje většině lidí je jiný.
  • 28. 7. 2005 13:08

    Pavel Tišnovský
    Pokud bych se měl v základních počtech opírat o to, co jsem se naučil ve škole, tak bych tak maximálně dokázal sečítat o odečítat, ostatní operace moderní mašinky (počítače, kalkulačky, mobily) jaksi nezvládají :-)

    Z těch šesti znamének (kromě číslic) platí pouze dvě, tak co s tím?
  • 4. 8. 2005 19:56

    Jakub Hegenbart

    BTW, jestli je to opravdu zavedený zápis, vždycky přeci můžu použít:

    #I( x = (a+b) / (c-d) )
    #I( attr(y) = z )

    Což se převede na
    (SETQ X (/ (+ A B) (- C D)))
    (SETQ (ATTR Y) Z)

    Nevypadá to téměř stejně? :-) Uznávám, že by bylo dobré mírně CL-INFIX modifikovat, kvůli tomu structu, ale syntaktický převod je ekvivalentní. Zkusím si ho někdy dát za domácí úkol. (Jestli se někdy dostanu domů... :-D) Navíc s objekty by to tak jako tak nefungovalo, CLOS není tak omezený, aby podporoval jen single-dispatch. A když už jsme u té srozumitelnosti jazyků:

    „No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence.“
    -- ALGOL 68 Report

    Ideální pro začátečníky, že? ;-)

  • 5. 8. 2005 8:21

    Pavel Tišnovský
    Neboj, co se člověk naučí v povinné školní docházce, může u počítačů stejně zahodit :-) (A to i v takovém Excelu, který by přece jen měl být pro uživatele přívětivější). Jak už jsem psal někde výše, tak se z těch šesti základních "znamének" (ne operátorů, prostě znamének používaných mimo čísla) používají pouze dvě v původním významu a zápisu.

    A to už nemluvím o funkcích atd., které se software od softwaru zapisují jinak - prefixově, postfixově atd. Prostě je v tom zmatek :-), takže vůbec není na škodu říct si dopředu: všechno bude v prefixu (LISP & spol.), všechno bude v postfixu (Forth, PostScript) a je vystaráno a dodefinováno - žádné složité tabulky s prioritami operátorů (viz C, C++, Java, Python atd.).

    Oni u HP moc dobře věděli, proč své kalkulačky udělali pro postfixový zápis...
  • 5. 8. 2005 20:20

    Petr Mach (neregistrovaný)
    To je omyl, ten způsob myšlení je jednou danný, proto jsou jazyky s Clike syntaxí tak oblíbené a používané.

    Oni všichni ostatní výrobci kalkulaček moc dobře vědí, proč používají normální zápis :-).
  • 5. 8. 2005 20:16

    Petr Mach (neregistrovaný)
    Tomu prvnímu přiznám, že to vypadá už lépe, ale psát každý výraz do #I() by se mi tedy nechtělo. To druhé, o jste si moc nepomohl :-).
  • 26. 7. 2005 17:13

    Pavel Tišnovský
    Jasně, v LISPu se při matematice můžete zamotat do závorek, hlavně s nesprávným editorem (:set lisp), na druhou stranu jsem ve svých programech moc matematiku nepoužíval (AutoLisp), spíš přístup k databázi entit a operace nad seznamy. [ale mě je to zrovna při matematice jedno, já se klidně "přepnu" mezi infixem, postfixem a prefixem bez potíží]. Stejně jsem měl vždycky největší potíže právě s infixem :-)

    S tím jediným jazykem jsem to myslel trošku obrazně, je asi nepravděpodobné, že by například všechny prohlížeče obsahovaly kromě JavaScriptu i Python (i když ty nejrozšířenější to díky API umožňují).

    Aha, já jsem to pochopil tak, že nějaká knihovna pro práci s DBF to tak dlouho načítá. Asi to bude hodně zdržovat i to vytváření výsledného PNG, přece jen při rozlišení cca 1000x9000 pixelů to dá zlibu (či co se skutečně volá) zabrat :-)

    Já jsem při tom zpracování DBF ve své podstatě tvořil rozdílové soubory, přičemž klíč pro porovnání byl dost dlouhý - tam už je rozdíl mezi PL/Sql a Cčkem znát (je to logické, protože si hodnoty v paměti přeskládám tak, abych to porovnal jedním průchodem a ne složitými konstrukcemi s andy atd).
  • 26. 7. 2005 9:19

    Petr Cernoch (neregistrovaný)
    zkousel jsem programek pro excel, mam python 2.4.1, standardni instalaci.
    Ale uz pri prvnim radku to hlasi:

    ImportError: No module named win32com.client

    takze nejenom u kritizovaneho pripadu s tcl je problem...
    Co s tim?

    Mimochodem, co kdyby jste napsal nejaky serial o pythonu? Jiste to privita spousta lidi.
  • 26. 7. 2005 10:41

    stefan (neregistrovaný)
    Je to jasne, potrebujete modul win32all z www.python.org, alebo ActivePython z www.activestate.com.
  • 26. 7. 2005 15:19

    Petr Mach (neregistrovaný)
    To je jednoduché, standardní instalace nestačí. Potřebujete rozšíření pro windows, jak se píše přímo na http://python.org/2.4.1/

    Windows users may also be interested in Mark Hammond's win32all package, available from Sourceforge. win32all adds a number of Windows-specific extensions to Python, including COM support and the Pythonwin IDE. Ke stažení např. zde:

    http://mesh.dl.sourceforge.net/sourceforge/pywin32/pywin32-204.win32-py2.4.exe http://starship.python.net/crew/mhammond/downloads/mfc71.dll

    O Pythonu bych psal rád, dokonce o tom uvažuji, ale nevím, kdy si na to najdu čas. Zatím mi stojí i Úvod do systému Linux, který mám rozepsaný.
  • 26. 7. 2005 13:49

    Jakub Hegenbart
    No, asi takhle: Kdysi jsem přecházel z BASICu na pascal/Cčko. Můžu Vás ujistit, že upgrade myšlení při přechodu pascal/Cčko (nebo cokoliv podobného jako třeba Python nebo Java) => LISP je stejný, ne-li větši. Není to komplikované, komplikované to je, pokud má člověk zatíženou hlavu minulostí...což rozhodně mám, bohužel :-)

    Nemá to naprosto nic společného se složitostí jazyka. Někde jsem viděl nějaké postřehy, že LISP a Smalltalk se mnohem snadněji naučí lidé, co nikdy neprogramovali, než ti, co programovali v nějakém strukturovaném nebo "objektovém" (zde "strukturovaném s nějakou tou dědičností tříd" ;-)) jazyku.

    Takže to není čas na prostudování manuálu, to je čas na napsání spousty kódu, osahání si programovacího stylu a změnu myšlení (které IMHO nebudou promrhané... ;-))

    Jeden kamarád se obtěžoval a napsal pro Vás dvě řešení ve Scheme (přesněji (+ R5RS SRFI-1 SRFI-11)), zřejmě mnohem rychleji než já... :o)

    http://www.volny.cz/sad0ur/collect/test.scm.html

    Mimochodem, co takhle výkonnostní benchmark toho kódu? CMUCL vs. Python? Ale to by nebylo ode mně fér... :-)
  • 26. 7. 2005 16:58

    Petr Mach (neregistrovaný)
    No, já bych řekl, pokud nikdy neprogramovali a nechodili do školy (nebo v ní aspoň nic nepočítali). Klidně tu složitost svedu na nutnost změny myšlení, které vyžaduje napsání spoustu kódu (on si člověk časem zvykne na všechno). Jak se říká, když to umíte, tak nic není složité. Takže složitost je vlastně obtížnost se dano věc naučit a pochopit ji. Také bych řekl, že třeba kvůli Céčku taky nemusíte studovat příliš dlouho manuál. Přesto je to jazyk, v kterém programovat je složité. Ono se stačí podívat, co obnáší GTK v Céčku a co v Pythonu :-).

    Děkuji za řešení, každý si teď může posoudit sám, co mu přijde srozumitelné a co ne.

    Výkonnostní benchamrk Pythonu klidně zkusit můžeme. Je jasné, že jako interpretovaný jazyk vyšší úrovně v tomhle zrovna zářit nebude, ne ve srovnání s kompilovanými jazyky, ale může to být zajímavé. O Pythonu se tvrdilo, že je pomalý i mezi interpretovanými jazyky. Ale to bylo kdysi, vím, že vývojáři na optimalizaci docela zapracovali, u každé nové verze ohlašují nějaké zrychlení (jednou snad dokonce dosáhli zrychlení 30 %) a tak by mě samotného zajímalo, jak si na tom dnes ohledně výkonu Python stojí. Zvláště ve srovnéní s jinými interpretovanými jazyky, jako je TCL, Perl a podobně. Připravím data :-).
  • 26. 7. 2005 17:19

    Pavel Tišnovský
    Na ten výkonostní benchmark jsem opravdu zvědavý (opravdu nevím jak to dopadne). Teď jde o to, jakou úlohu pro to připravit - ryzí výpočty, zpracování dat, práce se soubory? Chce to něco, kde se projeví přímo daný jazyk, ne jeho knihovny.
  • 27. 7. 2005 16:59

    Pavel Tišnovský
    Něco o výkonnosti programovacích jazyků je uvedeno na stránce: http://dada.perl.it/shootout/ (jméno domény tedy ve mně vyvolává jisté pochybnosti, ale mrkněte se na výsledky).

    Ještě dlouho sleduji stránku http://home.earthlink.net/~mrob/pub/lang_srom.html která na srovnání jazyků jde úplně jiným (řekl bych Googlovským) způsobem. Vizte například, jak si vedou C, Lisp a především můj chráněnec Forth :-).
  • 28. 7. 2005 0:55

    Petr Mach (neregistrovaný)
    Ty testy znam a jsou dost stare, sice tam ted uvadi novejsi verzi Pythonu nez driv, ale nejsem si jist, jestli s kazdou novou verzi kazdeho jazyka ty tabulky upravuji. Krom toho casto nesouhlasim s kodem, ktery je (nebo aspon byval) minimalne u pythonu napsan dost blbe. Treba jsem tam vidaval neco jako:
    try:
        lists[x].append(y)
    except:
        lists[x]=[y]
    
    Misto:
    lists.setdefault(x, []).append(y)
    Tj. pomoci vyjimek se zakladaji nove, neexistujici promenne, pritom v Pythonu na to existuje standardni konstrukce a vyjimky jsou v nem pomale. Nevim jestli to uz neni opravene, zkoumal jsem je dobre ped 1 - 2 roky a radu tech testu jsem dovedl optimalizovat pro vyssi vykon.
  • 26. 7. 2005 18:45

    Petr Mach (neregistrovaný)
    Takže benchmark.

    Data jsou tady: http://wraith.iglu.cz/python/ukazky/bench.lists/data.dat.bz2 cca 305 KB, po rozbaleni 7 MB.

    Kód je zde.
    # encoding: utf-8 
    
    import time
    
    t1 = time.time() # priprava dat
    
    data = open('data.dat')
    vysledky = []
    for line in data:
        a, b, v = line.split()
        vysledky.append((int(a)==1, int(b)==1, v))
    data.close()
    
    t2 = time.time() # test 1
    
    AB1 = [ v for a, b, v in vysledky if a and b]
    Ab1 = [ v for a, b, v in vysledky if a and not b]
    aB1 = [ v for a, b, v in vysledky if b and not a]
    ab1 = [ v for a, b, v in vysledky if not a and not b]
    
    t3 = time.time() # test 2
    
    AB2 = []; Ab2 = []; aB2 = []; ab2 = []
    for a, b, v in vysledky:
        if a and b:           AB2.append(v)
        elif a and not b:     Ab2.append(v)
        elif b and not a:     aB2.append(v)
        else:                 ab2.append(v)
    
    t4 = time.time()        
    
    print 'Příprava dat trvala %f s' % (t2-t1)
    print 'První test trval    %f s' % (t3-t2)
    print 'Druhý test trval    %f s' % (t4-t3)
    
    A výsledky jsou zde:
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 6.605488 s
    První test trval    3.123812 s
    Druhý test trval    1.611570 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 6.658894 s
    První test trval    3.189925 s
    Druhý test trval    1.623393 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 6.636448 s
    První test trval    3.207551 s
    Druhý test trval    1.616027 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 6.630546 s
    První test trval    3.181450 s
    Druhý test trval    1.624684 s
    
  • 26. 7. 2005 19:04

    Petr Mach (neregistrovaný)
    Jo, testováno v Pythonu 2.3.4 na platformě Linux a architektuře:
    [wraith@frodo ~]$ cat /proc/cpuinfo 
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 15
    model           : 2
    model name      : Intel(R) Pentium(R) 4 CPU 2.60GHz
    stepping        : 9
    cpu MHz         : 3121.705
    cache size      : 512 KB
    physical id     : 0
    siblings        : 2
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 2
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
    pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
    bogomips        : 6176.76
    
  • 26. 7. 2005 19:10

    Petr Mach (neregistrovaný)
    Po úpravě:
        vysledky.append((int(a)==1, int(b)==1, v))
    na:
        vysledky.append((a=='1', b=='1', v))
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 5.126848 s
    První test trval 3.094513 s
    Druhý test trval 1.562948 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 5.163060 s
    První test trval 3.137445 s
    Druhý test trval 1.569227 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 5.171682 s
    První test trval 3.089666 s
    Druhý test trval 1.550673 s
    
  • 29. 7. 2005 12:12

    Petr Mach (neregistrovaný)
    Copak? Nikdo není ochotný test implementovat ve svém jazyku?

    Ještě tedy dodám výsledky za použití knihovny Psyco, která v Pythonu některé operace urychluje:
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 3.537647 s
    První test trval 0.756269 s
    Druhý test trval 0.692954 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 3.397884 s
    První test trval 0.737806 s
    Druhý test trval 0.693551 s
    [wraith@frodo pokusy]$ python test.py 
    Příprava dat trvala 3.404836 s
    První test trval 0.735210 s
    Druhý test trval 0.698294 s
    
  • 29. 7. 2005 13:00

    Pavel Tišnovský
    Sorry, trošku to v práci nestíhám, tak jsem tomu dal nižší prioritu. Kdyby to někdo chtěl zkusit v Javě, tak by mi to bodlo (aspoň podle několika dokumentů hodně lidí Python a Javu porovnávají, asi podle té předkompilace do bytekódu). Je ale fakt, že ten program v Javě asi bude dost hnusný, ostatně celé souborové I/O Javy je takové vachrlaté :-(
  • 4. 8. 2005 0:18

    Petr Mach (neregistrovaný)
    No, takže už si nemusíme nic nalhávat. Rozdíl v použitelnosti Pythonu vs TCL nebo Lisp je značný, protože v Pythonu jsem ten test měl napsaný během chvilky a bylo mi to potěšením. V Lispu je asi problém to vůbec napsat, a TCL by to snad zvládnout mohl, ale zřejmě je to příliš velká dřina nebo by se ukázalo, že je zoufale pomalý.
  • 4. 8. 2005 8:10

    Pavel Tišnovský
    Ale to je trošku demagogie ne? Co když na to prostě zatím nemám čas? (teď jsem z práce jezdil místo domů přímo na chatu, kde mám jiné starosti než PCčka, takže jsem se k tomu opravdu nedostal :-)
  • 4. 8. 2005 10:44

    Petr Mach (neregistrovaný)
    Za víc jak týden? A tak najednou? A všichni? Hodně nepravděpodobné. V Pythonu je to otázka pár minut, proto jej také považuji za použitelný a proto jej mám rád, dělá se v něm snadno a rychle.
  • 5. 8. 2005 8:06

    Pavel Tišnovský
    No, spíš za LISP, ale k němu chybí taková vychytávka jako je Tk :-) Já jsem měl dojem, že se tady ta diskuse zvrhla na infix/postfix/prefix a Python/LISP.

    Teda abych úplně nekecal, v práci mám AutoLISP (vždyť v něm taky programuju), ale výsledky se díky tomu, že jde o čistý interpret, s kompilovaným Pythonem nedají srovnávat ne? [tím neříkám, že všechny LISPy jsou čisté interpretery, tak to není, ale Common Lisp v práci opravdu nemám, ani to Scheme]
  • 5. 8. 2005 14:35

    Jakub Hegenbart
    Nedávno se jeden můj přítel (mimo jiné také můj učitel hry na harfu na čádtečný úvazek :-)) začal přeučovat z AutoLISPu na Common Lisp/Scheme – ještě se úplně nerozhodl. (Nicméně říká, že žádný jiný jazyk než Lisp už kvůli jeho eleganci používat nechce. :-D) Co já se dozvěděl o programování v AutoLISPu, to jsem snad ani nechtěl vědět. :-) Dynamický scoping, samé SETy místo LETů... Radši jsem se AutoLISPu zatím vyhýbal, ale kvůli přítelovi se jím asi budu budu muset zabývat, abych si připomněl, co všechno pro něj musí být nezamozřejmé a co bych s ním měl radši pořádně probrat. :-)
  • 5. 8. 2005 15:43

    Pavel Tišnovský
    Ano, AutoCAD je postaven na starém XLispu a mnoho věcí z CommonLipsu v něm nejsou (a to už vůbec nemluvím o CLOS :-). Dynamický scoping až tak nevadí (stejně je to více Lispovské), ale spousta konstrukcí chybí a jejich dodělání pomocí (defun) a (lambda) je pomalé. Na druhou stranu to spojení s CAD systémem je naprosto geniální - opravdu si zde nedovedu představit jiný jazyk. Poslední dobou se v AutoDesku snaží o implementaci rozhraní k C-čku a také tam mají VBA, ale to je úplně o něčem jiném (asi jako psát regulární výrazy přímo v assembleru :-))).

    Naučte přítele CLOS, když zvládne toto, ostatní pro něj bude hračka :-))) [Osobně bych s ním však probral Scheme, to bude menší šok. Sice mě v něm vadí, že nil a T už nejsou co bývalo, ale co se dá dělat.]
  • 5. 8. 2005 16:10

    Jakub Hegenbart

    Já už mu daroval mu ANSI Common Lisp od Grahama. (Je to opravdu velmi dobrý přítel... :-)) Nicméně ve Scheme již cosi udělal, ale nadává na PLT Scheme pro jeho pomalost. Překvapí vás, že v době, kdy už měl nějaký ten software ve Scheme napsaný, jsem mu musel vysvětlit, jak že to je se statickým scopingem a k čemu slouží LET? (To bylo v souvislosti s otázkou "jak udělám funkci, která si mezi dvěma voláními bude něco pamatovat, třeba jako static proměnné v Cčku" :-)) Možná za to může ten AutoLISP... :-)))

    Stejně se domnívám, že nakonec zvládneme on i já (já jsem taky pořád v zácviku :-)) jak Scheme, tak i Common Lisp a pak si budeme moci vybírat podle potřeby. (I když, nevím, uvidíme, jestli já budu dřív umět hrát ha harfu nebo on pracovat s modernějším Lispem. Já věřím tomu druhému, on mě přesvědčuje o tom prvním... ;-))

  • 5. 8. 2005 16:22

    Pavel Tišnovský
    Jo, s tím LET bych to opravdu svedl na AutoLISP :-))) Já si ostatně myslím, že jak v CommonLispu, tak i ve Scheme je možné pracovat stejně jako se starými (klasickými) LISPy, tj. funkcionálně bez proměnných, smyček atd. Samozřejmě to je pomalejší, zejména když není implementováno tail-recursion.
  • 5. 8. 2005 18:04

    Jakub Hegenbart
    Já se snažím psát rekurzivně tam, kde to je přirozené, občas zase přijde vhod ten loop/iterate...podle nálady a potřeby. Je fajn, že LISP se nebrání témeř ničemu a zvládá to výkonnostně dost s přehledem. :-) Což je ostatně důvod, proč ho používám... :-D
  • 5. 8. 2005 20:29

    Petr Mach (neregistrovaný)
    Rozhodně ne, s LISPem si tu přihřívá polívčičku někdo jiný. Já diskutuji o Pythonu vs, TCL o kterém je článek pod kterým diskutujem. Zajímá mě jeho výkon a těším se na implementaci toho testu v TCL.
  • 5. 8. 2005 20:46

    Petr Mach (neregistrovaný)
    Teda abych úplně nekecal, v práci mám AutoLISP (vždyť v něm taky programuju), ale výsledky se díky tomu, že jde o čistý interpret, s kompilovaným Pythonem nedají srovnávat ne? [tím neříkám, že všechny LISPy jsou čisté interpretery, tak to není, ale Common Lisp v práci opravdu nemám, ani to Scheme]

    Ano, nikdo to nemá, to je problém ukazující reálnou používanost těchto jazyků :-). Ale to je jedno, to je jen takové pošťouchnutí.

    Spíš mě překvapuje oháněním se tím, že interpretovaný vs. kompilovaný. Znovu opakuji, Python je jazyk interpretovaný, stejně jako PHP nebo Perl. S kompilovanými jazyky jako C a asi i Lisp nemá nic společného.
  • 8. 8. 2005 8:43

    Pavel Tišnovský
    Pokud vezmu počítači používané v práci, tak jednoznačně vede Lisp (konkrétně AutoLISP) a Java. Pouze dva tady máme C-čko a Tcl, takže vše je relativní (jo zapoměl jsem na JavaScript, ten mají v prohlížeči i sekretářky :-).

    S tou kompilací vs. interpretací: program v Pythonu je před svým spuštěním zkompilován do svého bytekódu - je to tak? Nebo je v paměti přímo zdroják? Lisp není už z principu kompilovatelný (bohudík za takový jazyk :-), proto se opravdu kompiluje pouze do nějakého bytekódu, nikdy se z něj nedá udělat čisté .exe (jedině s přibundlovaným interpreterem Lispu, což se taky docela často děje). Když jsme u toho Tcl, tak to je vyloženě interpretované řádek po řádku (viz Vaše problémy s přenosem ze schránky). Má to samozřejmě své výhody i nevýhody.

    > But, I guess my question boils down to, why is not Python a compiled
    > language?

    The unhelpful answer: it is! It compiles to a high-level bytecode.
    See other replies for info about compiling to a lower-level
    instruction set...

    > How can I decompile a python PYC file to see the source?

    You cannot. .pyc files are bytecode, and you can only disassemble them
    into a representation of bytecode. That's not as low-level as
    machine-code, but it's not Python code either ! See the 'dis' module on
    how to disassemble.

    Toto byl v minulosti docela problém s AutoLISPem, kdy si firmy programující v něm své nadstavby chtěly chránit zdrojáky. Řešilo se to pomocí různých "začmodrchávačů" kódu, vždy však šlo o Lispovský zdroják (ty nadstavby mnohdy stály více než celý AutoCAD).
  • 11. 8. 2005 9:50

    Petr Mach (neregistrovaný)
    JavaScript je pěkný jazyk, ten mám rád, prototypová dědičnost se mi líbí, škoda že ji má IE blbě implementovanou.

    Ano, bytekód se vytváří, ale já kompilaci vnímám překlad programu do instrukcí procesoru. Bytekód Pythonu nevykonává procesor ale interpret, proto je to jazyk interpretovaný, ne kompilovaný. Bytekód je jen výsledek parsingu zdrojového kódu, je to pořád ten zdroják, jen ve formě, které rozumí interpret. Takto imho funguje většina interpretovaných jazyků, zaručeně Perl a PHP. Python má akorát navíc tu vychytávku, že tento bytekód ukládá do souboru, takže při příštím spuštění programu se nemusí zdroják znovu parsovat. To zrychluje spuštění programu, ale ne jeho vykonávání. Program v Pythonu nemusíte před spuštěním překládat nebo něco takového, děje se tak transparentně na pozadí (a pokud bytekód uložit nejde, třeba proto, že se spouští z CD, tak se nic neděje). Proto se také do souboru neukládá bytekód zdrojáku který spouštíte, to se děje jen u natahovaných modulů. Takže v případě těchto jednoduchých jednosouborových ukázek se soubory s bytekódem ani nevytváří, vytváří se při každém spuštění programu a je jen v paměti interpretu. A nakonec, něco jako kompilátor Pythoního programu neexistuje, má jen interpret.

    Jestliže TCL (a nechce se mi tomu věřit) bytekód vůbc nevytváří, pak to znamená, že při běhu programu musí každý řádek programu parsovat znova a znova pořád dokola. To je primitivní a musí to být extrémně pomalé. Chápu pak, proč ten benchmerk odmítáte v TCL udělat. ale i tak se dá říct, že TCL používá bytekód, a to aktuálně zpracovávaného řádku, ne? :-)
  • 11. 8. 2005 10:19

    Pavel Tišnovský
    Taky se mi JavaScript líbí, škoda, že ho nemám na straně serveru (je nějaká volně dostupná implementace kromě věcí od IBM a Netscapu?).

    Dobře, tady se rozcházíme v pohledu na to, co je překladač a co interpreter :-) Sice potom nevím, co jsou to Pascalovské a Javovské kompilátory ale dobře, dá se to chápat tak, že bytekód je určitým nekompatibilním procesorem interpretován. Opravdu má Python bytekód vytvářen tak, že je to pouze předkousaný zdroják? (mám zde na mysli rozdíl mezi tokenizovaným Basicem a opravdovým Pascalovským a Javovským bytekódem).

    U Tcl je možná jak interpretace, tak i překlad do bytekódu (http://www.tcl.tk/software/tclpro/compiler.html). Každý přístup má své výhody i nevýhody - ostatně právě proto jsou skriptovací jazyky vymyšleny, aby obešly některé nevýhody kompilovaných jazyků. Python v případě interpretace pracuje podobně jako Tcl, tj. zpracovává vstup řádek po řádku (a interně si dělá nějaký mezikód), přičemž však věci jako eval() nebo $a$b nelze dopředu přeložit, podobně jako v JavaScriptu.

    Benchmark jsem zatím neudělal ze dvou důvodů: málo času odpoledne a neexistence Tcl na pracovním počítači (teď nemyslím interpreter, ale kompiler). Málo času=děti, cvičení, články na Root, jeden menší projektík mimo práci :-)
  • 4. 8. 2005 17:25

    Jakub Hegenbart
    V tuto chvíli jsem v práci od včerejšího rána, snad vypadnu do neděle. Tumáte aspoň nevyladěný draft: Common Lisp
    Příprava dat trvala 15.422000 s
    První test trval    3.875000 s
    Druhý test trval    2.000000 s
    
    ==================
    
    [4]> (load "test.fas")
    ;; Loading file test.fas ...
    Real time: 11.421875 sec.
    Run time: 10.140625 sec.
    Space: 136005080 Bytes
    GC: 24, GC time: 3.578125 sec.
    Bytes permanently allocated:       66792
    Bytes currently in use:         33629196
    Bytes available until next GC:   8407299
    Alokovanych bajtu: 33629196
    
    Real time: 0.703125 sec.
    Run time: 0.671875 sec.
    Space: 8000032 Bytes
    Real time: 0.78125 sec.
    Run time: 0.734375 sec.
    Space: 8000032 Bytes
    AB: 250788
    aB: 249885
    Ab: 249285
    ab: 250042
    ;; Loaded file test.fas
    T
    Sempron 2500+, DDR SDRAM 266 MHz paměti. Tohle jsou Windows 2000, CLISP 2.34 a Python 2.4.1. Zkoušel jsem ještě CMUCL kompilátor v Linuxu, tam to bylo asi 0.6 sekundy, ovšem stroj byl 300 MHz P II. Zkusím CMUCL i na tom Sempronu a hlavně zapnu v kompilátoru nějaké ty optimalizace, tohle je off-the-head kód, který si jen tak funguje, ale asi moc hezký není. Jo a Python spotřeboval asi 90 MB paměti, CLISP asi 40 MB. To se podle mě taky počítá...
  • 4. 8. 2005 21:45

    Jakub Hegenbart
    Takze vysledky z Linuxu na Sempronu:

    CLISP: LOOP makro 0,7 s, DOLIST makro 0,8 s.
    CMUCL: LOOP makro 0,16, DOLIST makro 0,19 s.
    Vysledky po nekolika spustenich jsem ani nemusel prumerovat, rozchazely se jen o jednu-dve jednotky v druhe vyznamne cislici.

    Preci jen si ale myslim, ze CMUCL ma na vic. Zkusim to kdyz tak s nejakymi typovymi deklaracemi, ale nejprve si poridim poradnou instalaci desktopoveho linuxu, ten rok a neco neudrzovany Slackware potrebuje nahradit. :-) A podivam se na vystup makroexpanderu. Ze LOOP je rychlejsi nez DOLIST, ktere by melo byt trivialne jednoduche a tedy rychle, to me docela prekvapuje a zajimalo by m2, co se deje uvnitr. (Ale u LOOP makra by se mozna clovek ani nemel divit, je tak komplexni, ze jeho jedinou autoritativni referenci je primo jeho zdrojovy kod. Mozna i proto vzniklo makro ITERATE, ktere se celkove zda byt lepsi, jen se ho musim naucit... :-))
  • 5. 8. 2005 8:12

    Pavel Tišnovský
    Nebude ten rozdíl v rychlosti dán spíše tím použitím (cond) a if? Přecejen ty ify jsou do sebe vnořené, takže se někdy ušetří jedna podmínka (neprochází se druhá nadřazená větev), kdežto (cond) so to pěkně proleze všechno. Teda možná kecám, Tvůj příklad jsem upravovat zatím nezkoušel, ale v sobotu a neděli jsem doma (heč), takže se na to mrknu.
  • 5. 8. 2005 14:43

    Jakub Hegenbart
    To ale nejsou IFy. Tedy ne speciální formy IF – jen nějaké symboly IF, které si přechroustá LOOP. Ve skutečnosti by se jak LOOP, tak DO měly transformovat v podmínkách na IF. Schválně si vyzkoušejte v CLISPu třeba tohle:
    (macroexpand '(cond ((= a 1) 12)
                        ((= a 2) 35) 
                        ((= a 3) 551) 
                        (t 3214)))
    Výsledek by měl být něco jako
    (IF (= A 1) 
        12 
        (IF (= A 2) 
            35 
            (IF (= A 3) 
                551 
                3214)))
    Což je na LISPu naprosto skvělé, člověk si může spoustu vnitřností prohlédnout takhle jednoduše. :-)
  • 5. 8. 2005 20:40

    Petr Mach (neregistrovaný)
    No, nějak se v těch výsledcích nemohu vyznat. Udělat časové značky, se stejným výstupem, jako má můj test není v LISPu možné?

    Co se týče dvojnásobných nároků na paměť, tak jestli chápu váš kód, tak vy každý test spouštíte ve vlastní funkci a po ukončení funkce jsou ty seznamy odstraněny z paměti. V mé ukázce seznamy v paměti zůstávají a v každém testu se plní jiné, takže po této stránce nejsou ty programy srovnatelné. Ale vyšší paměťová náročnost je Pythonu jako dynamickému interpretovanému jazyku s vysokoúrovňovými datovými typy blízká.
  • 10. 8. 2005 19:41

    Jakub Hegenbart
    Nerouzumím jedné věci, proč dělat primitivní časové značky, když CMUCL mi napíše wallclock time, user time, system time a přesný počet cyklů procesoru? :-)
  • 11. 8. 2005 17:48

    Jakub Hegenbart
    To není zapotřebí. Já píšu v Common LISPu, Common LISP to umí (i.e. TIME je standardizované a přenositelné, ač výstup není přesně definován, ale základní údaje tam budou vždy), a pokud ho GCL neumí, je to problém jeho kompatibility a ne problém Common LISPu. :-) Mimochodem, já zase nemám Psyco, posledně mi negungovalo, takže ten "optimalizovaný" benchmark taky nerozchodím a jsme si kvit. ;-)
  • 4. 8. 2005 17:34

    Jakub Hegenbart
    No a já zase o deštivém víkendu spal v Českém ráji v díře ve skále ve spacáku... :-) Aneb „Get a real life...“ (I do have one. ;-))
  • 4. 8. 2005 17:31

    Jakub Hegenbart
    Napsání Lispovské funkce: Pár minut. Sehnání linuxového stroje s LISPem, když člověk běží nouzově na starém notebooku s Windows (SW nutnost) a ke svému stroji, který je někde jinde, se hned tak nedostane: Pár dní. :-) Asi tak. A mě to náhodou bylo taky potěšením, náhodou jsem si při tom připomněl, co že všechno umí destructuring-bind :-D Akorát poslední týden na potěšení není čas, pitomé termíny... :-(
  • 5. 8. 2005 20:27

    Petr Mach (neregistrovaný)
    Ano, to je krutá pravda o Lispu. Najít počítač s Lispem není jednoduché, ale to je jeho další nevýhoda. Ani na mém linuxu není k dispozici. Hledal jsem na netu a našel nějaký gcl = GNU Common Lisp, ani za boha nemohu přijít na to, jak ten váš kód spustit. Logické "gcl test.lisp" nefunguje, spustí se interaktivní interpret. Člověk si musí zvyknout, že v Lispu není nic logické a intuitivní. Poradíte mi, jak to mám spustit a nebo co jiného si mám nainstalovat? Jsem na GPRS, tak pokud by to mělo do 10 MB, tak by to bylo fajn. Nějak se v těch Lispech nemohu vyznat. Jak to je vlastně se vzájemnou kompatibilitou kódu, knihoven a tak dále? Na to jak je Lisp málo používaný se mi zdá dost roztříštěný.
  • 7. 8. 2005 20:47

    Petr Mach (neregistrovaný)
    Tedy, nechci být kverulan, ale ještě se mi to pořád nepodařilo spustit a nedokážu přijít na to, jak to spustit. Zjistil jsem, že mohu dát příkaz gcl -compile test.lisp a výsledkem je soubor test.o, co mám udělat dál?
  • 7. 8. 2005 22:29

    Petr Mach (neregistrovaný)
    Jestli z tohodle http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_183.html#SEC183 někdo pochopí, jak se kompiluje, může mi to vysvětlit. A ať mi nikdo neříká, že to není složitý jazyk. A ještě se mi zdá špatně dokumentovaný, nemohu najít žádný tutorial, examples nebo něco podobného. Ale i rozhoduje o tom, jak je jazyk dobrý a použitelný.

    Ale přeci jen jsem něčeho dosáhnul, s parametrem -load se to dá spustit. Nejprve jsem tedy bojoval s tím, že jsi přejmenoval datový soubor, v té záplavě hlášek se to chybové hlášení ztrácelo. Potom jsem musel ze zdrojáku vypreparovat odkazy na GC, protože takové funkce jsou prý neznámé (znovu se ptám, jak snadno jsou přenositelné programy mezi jednotlivými implementacemi Lispu?) a pak konečně výsledek.
    real time       :      5.520 secs
    run-gbc time    :      4.130 secs
    child run time  :      0.000 secs
    gbc time        :      1.280 secs
    real time       :     13.990 secs
    run-gbc time    :      6.100 secs
    child run time  :      0.000 secs
    gbc time        :      7.790 secs
    real time       :      3.980 secs
    run-gbc time    :      2.350 secs
    child run time  :      0.000 secs
    gbc time        :      1.630 secs
    
    Jestli to chápu, tak načtení datového souboru 5,5 s, a dva různé testy 13,9 s a 3,9 s. No, jako interpret tedy nic moc. Jestli mi někdo poradí, jak to zkompilovat, budu rád. Také by mě zajímalo, jak to spustit, aniž bych po skončení programu zůstal viset v interaktivní konzoli, za prvé mě to rozčiluje, za druhé pak programy v lispu takto nejde spouštět třeba ze skriptů.

    Já jsem si zatím udělal pro Python verzi optimalizovanou na rychlost:
    import time, psyco, gc
    psyco.full()
    
    def run():
    
        t1 = time.time()
        data = [(x[0]=='1', x[2]=='1', x[4:6]) for x in open('data.dat')]
        t2 = time.time()
        AB, Ab, aB, ab = [], [], [], []
        for a, b, v in data:
            if   a and b:      AB.append(v)
            elif a and not b:  Ab.append(v)
            elif b and not a:  aB.append(v)
            else:              ab.append(v)
        t3 = time.time()
    
        print 'Data: %.3f s' % (t2-t1)
        print 'Test: %.3f s' % (t3-t2)
        
        return data, AB, Ab, aB, ab
    
    t=time.time()
    gc.disable()
    run()
    gc.enable()
    print 'Run:  %.3f s' % (time.time()-t)
    
    A spustil ji ve windows v Pythonu 2.4, výsledky jsou fajn:
    F:\proj\test>python test.py
    Data: 0.453 s
    Test: 0.187 s
    Run:  0.859 s
    
    F:\proj\test>python test.py
    Data: 0.453 s
    Test: 0.188 s
    Run:  0.844 s
    
    F:\proj\test>python test.py
    Data: 0.454 s
    Test: 0.187 s
    Run:  0.860 s
  • 10. 8. 2005 19:51

    Jakub Hegenbart

    Mimochodem, za takovéhle příspěvky by se asi v newsgroupě objevilo "RTFM". Snad si umíte přečíst dokumentaci, ne? Implementace GC je překvapivě záležitost implementace, ne jazyka, který od toho odstiňuje a dost možná je v jeho specifikaci výslovně zmínka, že tyhle věci se v normě jazyka _neřeší_. Schválně se podívám. Kód, který jsem poslal, je spustitelný v CLISPu a CMUCL, jak jsem psal. Až mi váš kód nebude fungovat v IronPythonu nebo v Jythonu, mám taky začít nadávat?

    A pokud se chcete naučit Common LISP nenásilnou formou, zkuste třeba http://www.gigamonkeys.com - ta knížka je výborná. Je to Common LISP, tak, jak je popsaný v HyperSpecu, ne konkrétní implementace - radši to předesílám předem.

  • 11. 8. 2005 8:21

    Pavel Tišnovský
    Díky za odkaz, ta knížka je opravdu pěkná. Ještě se mi líbí dokument "Revised(5) Report on the Algorithmic Language" Schemehttp://www.swiss.ai.mit.edu/~jaffer/r5rs_toc.html - je to docela čtivý a současně i úplný popis Lisp-like jazyka (== Scheme je pro začátečníky :-).
  • 11. 8. 2005 9:12

    Petr Mach (neregistrovaný)
    Také děkuji za odkaz.

    Až vám dám kód v Pythonu, který nepojede v IronPythonu nebo Jythonu a nebude to z důvodu absence knihovny, tak mi začněte nadávat. Jinak IronPython a Jython vznikly právě proto, aby bylo možno používat místo vlastního prostředí (knihoven) jejich prostředí (knihovny .NET a Javy a aby ten program běžel v jejich interpretu). Není tu ale deset různých nekompatibilních implementací Pythonu pro to samé prostředí. Tohle skutečně hodnotu Lispu snižuje.
  • 11. 8. 2005 9:29

    Pavel Tišnovský
    Ještě k tomu možná dodám odkaz na Corman Lisp, což by měl být překladač (:-) pro Common Lisp na třicetidvoubitových Windows. Co je na tom pěkné, je možnost volat služby WinAPI, takže se Lispový prográmek může po překladu chovat jako nativní Windowsovská aplikace (to je to, co tady bylo na Tk kritizováno - absence rozhraní pro "nové" GUI knihovny).
  • 11. 8. 2005 17:54

    Jakub Hegenbart

    „Není tu ale deset různých nekompatibilních implementací Pythonu pro to samé prostředí. Tohle skutečně hodnotu Lispu snižuje.“

    Tak tohle jsem nepochopil. Jednak ta nekompatibilita je pouze v nestandardizovaných věcech, což je typicky malá část programu (a už jsem to v mnohla LISPovských kódech viděl, třeba 200-300 kB kódu společného a 5-15 kB kódu pro každou implementaci - de facto hnída), jednak - proč je možnost výběru nevýhodou? Prostě si vyberte jednu implementaci, tu používejte, na ostatní zapomeňte...lo and behold! Máte jednu implementaci. ;-)

    BTW, ty tři implementace Pythonu jsou na tom asi stejně jako ty LISPy - každý je dobrý v něčem jiném, pokud jde o interakci se zbytkem světa.

  • 8. 8. 2005 8:30

    Pavel Tišnovský
    Tak teď nevím, jak tomu mám rozumět. Lisp není pouze jedna jeho implementace, právě naopak. Jedná se o jazyk, který se mimo jiné používá pro skriptování aplikací, psaní standalone kódů, paralelní programování. Z toho logicky vyplývá, že bude roztříštěný, alespoň co se týče knihoven (nutno však podotknout, že knihovny jsou do značné míry přenositelné). Myslím, že na svém počítači alespoň nějaký Lisp máte, zkuste guile (když používáte GTK). Emacs předpokládám nemáte :-) [já taky ne]

    C-čko je IMHO taky dost roztříštěné o C++ a jeho knihovnách ani nemluvě :-)

    [To, že nějaký program nejde spustit, jsem si zvykl i u jiných jazyků. Zkoušel jsem například to GUI v Pythonu (Váš příklad někde na vrchu této diskuse) a napsalo mě to hlášku ve stylu "Požaduji knihovny xxx.xxx, ale nejsou k dispozici". Nejlepší je, že to ani nenapsalo verze požadovaných knihoven. Takže tím jsem skončil, alespoň u mě doma.]
  • 8. 8. 2005 15:34

    Petr Mach (neregistrovaný)
    No právě že není. Chápu, že jeho embeded v nějaké aplikaci slouží ke skriptování té aplikace a nenabízí vše, co standalone verze, ale to není náš případ, že? Stáhl jsem si standalone implementaci lispu a zkusil v ní spustit zde zveřejněný standalone skript.

    Že by měl být roztříštěný, to mi z toho logicky nevyplývá. Třeba jazyk C je standardizován jako ANSI C a pokud píšete v souladu s tímto standardem, tak máte zaručenu vysokou přenositelnost mezi překladači.

    Je samozřejmě jasné, že žádný překladač/interpret si sebou netahá všechny existující knihovny, to není prakticky možné. Ale opět mi to nepřijde jako tento případ, nikde v tom Lispu nevidím volání nějaké knihovny, takže to podle mě není problém chybějící knihovny.

    No, Guile je podle mě Scheme (ne zcela kompatibilní) a ne Lisp, ale zkusil jsem tedy příklad v něm, podle očekávání: ERROR: Unbound variable: defun. Přepíšete ten příklad tak, aby to v Guile fungovalo? Jsem na výkon Guile docela zvědavý.

    To že program nejde spustit bez potřbné knihovny není nic překvapujícího, ale jak říkám, v tom příkladu se žádná externí knihovna nevolá, je to tedy úplně jiná situace a proto mluvím o roztříštěnosti. Teda doufám že Lisp má prostory jmen, protože jestli ne a všechno cpe do jednoho, tak patří mezi primitivní jazyky a můj již tak nízký zájem by nabyl záporných hodnot. Ale v takovém případě bych přinejmenším očekával, že ta funkce se nebude jmenovat gc, ale knihovna_gc, aby se aspoň snížila pravděpodobnost konfliktu názvů funkcí z různých knihoven.

    Nejlepší je, že to ani nenapsalo verze požadovaných knihoven.
    Co je na tom nejlepšího? Jestli programátor (já) napíše "import gtk", tedy nahrej knihovnu gtk, tak jak má interpret pythonu vědět, jaká verze je požadována? V takovém případě vyvolá standardní výjimku, a je na mě, programátorovi, jestli ji zachytím a a poskytnu uživateli nějaké přídavné informace nebo se spokojím se standardním hlášením: ImportError: No module named gtk. To je imho srozumitelné hlášení, které říká, že si musíte nainstalovat gtk pro Python, ne? Ale je pravda, že jsem se mohl zmínit, že gtk je nadstandardní knihovna, tj. že není součástí distribuce Pythonu.

    Jestliže je Lisp skutečně příšernost mající jen jeden prostor jmen, pak je možné, že gc je špatně nazvanou funkcí nějaké knihovny (tím na mě tedy Lisp dobrý dojem nedělá, doufám že tu někdo vysvětlí, jak se přesně věci mají). Bohužel nevím jaké, kde ji získám a jak ji nainstaluju. Dokážete mi na ni dát odkaz?
  • 8. 8. 2005 16:52

    Pavel Tišnovský
    Právě že o tu roztříštěnost jde. Například C-čko by už mělo být dost dlouhou dobu standardizované. Ale který překladač je dnes standardní? Dobře, blíží se tomu GCC, ale pouze při použití k tomu určených knihoven a při zadání -c99. Zrovinka dneska se na Rootu objevila zprávička, že byl přidaný nějaký patch do zdrojáků jádra, takže to nepůjde přeložit na starších překladačích. Takže je to buď v knihovnách, nebo v samotném jazyku. (a už vůbec nemluvím o překladačích na signálové procesory, kde je například "char" třicetidvoubitový :- - co na to říká norma, zejména ve spojení s operátorem sizeof() a funkcí malloc()?). Podobné je to v Lispu, kde je již dost dlouhou dobu standardem Common Lisp.

    Ano, Guile je implementace Scheme, ale Scheme není zas nic jiného než "akademický" Lisp, tj. některé rozšafnosti s Common Lispu tam chybí a na rozdíl od běžných Lispů je zde přesně řečeno, kdy se provádí tail-recursion (já vím, že je to maličkost ale potěší).

    S tím Pythonem se ještě domá podívám, co přesně to píše. Akorát si pamatuji, že mě to připadlo legrační. Samozřejmě knihovny pro GTK (i Qt) mám, teď jde o to, jestli na sebe sedí verze. Určitě poreportuju, už jen proto, že si to chci opravdu vyzkoušet.
  • 8. 8. 2005 17:57

    Petr Mach (neregistrovaný)
    Já bych řekl, že takovou jednoduchou věc, jako načíst obsah souboru se v C dá napsat přenositelně velmi dobře. Jádro je už přeci jen jiná kategorie, navíc je doslova psané na míru gcc a využívá jeho různé nestandardní featury.

    Ad signálové procesory. To už je zase otázka architektury procesoru. Opět jiný problém, než se zdejší ukázkou v Lispu, kde se nejedná o problém rozdílných architektur.

    Ad Guile. Tak proč ta ukázka v něm tedy nefunguje? Ja snad tak špatně napsaná a je to chyba programátora?

    GTK+ knihovna napsaná v C jazyku, takže samotná samozřejmě nestačí. Ještě je potřeba binding pro příslušný jazyk. Myslel jsem, že programátorům je tento fakt známý, je to obvyklý jev a to samé se týká třeba i toho Guile. Doporučuji prostudovat: http://gtk.org/bindings.html

    Binding pro Python se distribuuje pod názvem PyGTK (což je onen gtk modul, který se importuje) a v Linuxových desktopových distribucích je obvykle defaultně nainstalovaný, nebo je alespoň k dispozici jako připravený balíček. Nemáte-li balíček pro svoji distribuci, pak zdrojáky jsou k nalezení zde: http://ftp.acc.umu.se/pub/GNOME/sources/pygtk/2.6/ a binární port pro windows je zde: http://www.pcpm.ucl.ac.be/~gustin/win32_ports/

    Jediný problém by mohl být, kdybyste měl nějakou historickou verzi linuxu a v ní nainstalován PyGTK pro GTK1, který je nekompatibilní s tím pro GTK2, což je dáno tím, že GTK1 samotné je nekompatibilní s GTK2. Pak by vám to hlásilo, že v modulu gtk není ta nebo ona funkce přítomna. V době přechodu mezi těmito toolkity se to v Pythonu řešilo tímto způsobem:
    import pygtk
    pygtk.require('2.0')
    import gtk
    
    Ale dnes už to nepoužívám, protože většinou mám prostředí kde mé aplikace poběží pod kontrolou a GTK1 je už mrtvé.
  • 10. 8. 2005 8:29

    Pavel Tišnovský
    Právě že ANSI C by mělo být přenositelné prakticky na jakoukoli platformu. U těch signálových procesorů jsme narazili spíš na nekorektní chování operátoru sizeof() a funkce malloc(). Není přece problém mít chary na 32 bitech. Co však vrací sizeof() a akceptuje malloc() - je to velikost v bytech nebo v charech? Teoreticky by to mělo být jedno, ale pouze za předpokladu, že se jak sizeof(), tak i malloc() na těchto věcech shodnou - a přesně toto nedělají. Je však pravda, že C-čko je - alespoň z jazyků, které jsem používal - nejpřenositelnější. Nejdřív jsem si to myslel o Javě, ale po několika pokusech s různými prostředími si to už nemyslím :-) [člověk musí hlídat některé nekompatibility v knihovnách, verzích JVM atd.]

    Lispy se hodně liší (možná jsem to v předchozím příspěvku nezdůraznil). Dokonce to jde tak daleko, že pro definici funkcí se používají rozdílně pojmenované funkce s rozdílnou sémantikou :-) Řekl bych, že přenositelnost Lispovských zdrojáků mezi různými interpretery je maximálně na úrovni standardních knihoven, ale to přičtěte tvůrcům těchto interpreterů nebo vlastnosti Lispu být prostě všude (stejně to tak platí pro, dejme tomu, Forth a Basic - velmi snadno implementovatelné jazyky).

    Nejsem tak tupý, jak to možná z mých příspěvků vypadá :-) S bindingem je mi to samozřejmě jasné, PyGTK mám nainstalovaný, nevím, zda je půl roku stará distribuce historická atd. Ale překvapila a pobavila mě hláška typu: "This app requies module %u.%u but have module %u.%u" (přesné znění mám doma na počítači, donesu a pošlu). Mě to tedy zábavné přijde - někdo (tvůrce aplikace) se snažil mi problém přesně popsat (čímž mu děkuji), ale jaksi zapoměl za ty %u dosadit ty správné integery :-)
  • 11. 8. 2005 9:18

    Petr Mach (neregistrovaný)
    Moment, bavíme se o přenositelnosti C nebo programů v něm napsaných? Protože v ANSI C lze naprosto jednoduše psát programy, které jsou mzi různými architekturami nepřenositelné, stačí spoléhat na konkrétní velikost datového typu, který se na různých architekturách liší.

    Ano, už jsem pochopil, že tu je milion Lispů a každý jiný. Já jim to mám za zlé.

    Na tu hlášku jsem zvědavý, ještě jsem se s tím nesetkal, není to standardní chování. Půl roku není stará distribuce. To je tak RedHat 7.x, nebo kdy se přecházelo z GTK1 na GTK2.
  • 11. 8. 2005 9:42

    Pavel Tišnovský
    Problém je možná v samotné normě. Alespoň do té míry, co se mi podařilo dohledat, tak sizeof(char) vrací definitoricky jedničku, kdežto malloc() vyžaduje zadání velikosti alokované paměti v bytech. To není problém na platformě x86, kde je velikost charu skutečně jeden byte. Problém nastává na platformách, kde je char třeba třicetidvoubitový. Potom už příkaz:

    malloc(sizeof(char)*velikost)

    není korektní, resp. alokuje méně paměti.

    It's never necessary to multiply by sizeof(char), since sizeof(char) is, by definition, exactly 1. (On the other hand, multiplying by sizeof(char) doesn't hurt, and may help by introducing a size_t into the expression.) See also question 8.9.

    References: ANSI Sec. 3.3.3.4
    ISO Sec. 6.3.3.4
    H&S Sec. 7.5.2 p. 195

    Ve všech dalších případech jsem se s problémem velikosti proměnných nesetkal, chce to sice trošku si pohrát s makry a souborem <limits.h>, ale jde to.

    Ještě je zajímavé, že podle C standardu (ANSI) není zaručeno, že se alokuje více než 32 kB kontinuální paměti :-). Zatím mi to tedy vždy fungovalo, protože size_t je většinou 32 bitové, ale nedá se vyloučit, že na embedded systémech to nebude fungovat (kdo tam však bude používat C-čko, že?).
  • 12. 8. 2005 8:30

    Pavel Tišnovský
    Už jsem si konečně našel čas a našel tu hlášku, kterou mi Python dává při spuštění jednoho skriptu:

    "RuntimeError: the sip module supports API v%u.0 to v%u.%u but the %s
    module requires API v%u.%u"

    Já samozřejmě nemám nic proti tomu, že to vypíše chybu o tom, že je tam špatná knihovna, to se stane v každém jazyku. Ale ty nenaplněné formátovací znaky mě tedy rozesmály :-)
  • 8. 8. 2005 17:18

    Pavel Tišnovský
    Ale musím říct, že s tou standardizací Lispu to není moc slavné. Holt se nejedná o jazyk, pro který by se díky jeho komerční (!) síle vyplatilo skládat komisi a nějaký standard definovat. Tím novým standardem mělo být Scheme, což byl zcela jistě dobře míněný nápad, ale přecejen je Scheme o něco "slabší" než Common Lisp (knihovny atd).

    Když už se bavíme o různých verzích, tak se mrkněte na stránku http://community.computerhistory.org/scc/projects/LISP/ a uvidíte vývoj mnoha větví tohoto jazyka (on je zhruba stejně starý jako Fortran, narozdíl od Fortranu však má smysl se tento jazyk alespoň zhruba naučit - minimálně kvůli stylu myšlení - to stejné platí i o Forthu).
  • 8. 8. 2005 18:23

    Petr Mach (neregistrovaný)
    Python také není komerční :-). Ale nikdo nemá potřebu dělat nekompatibilní implementaci, spíš se rozšiřují jeho knihovny, to mi přijde užitečnější. Jsou dvě speciální implementace Pythonu a to Jython a IronPython.

    Jython je port Pythonu do prostředí Javy. Program se překládá do bajtoveho kódu JVM v kterém se spouští. Může (a je to cíl) koexistovat s kódem Javy. Je odkázán na prostředí Javy, tj. nepoužívá C knihovny C Pythonu, což je pochopitelné, JVM něco takového neumožňuje.

    IronPython je to samé v bledě modrém, pouze místo Java prostředí se využívá .NET prostředí. IronPython je teprve v alpha verzi.

    Ten jiný styl myšlení je právě to, co se mi na Lispu líbí nejmíň. Dám radši přednost jazyku s normálním stylem myšlení, protože v tom umím myslet a dobře programovat. Za jiný styl myšlení má u mě Lisp mínus. Ale jsou i jiná kritéria, která by mě mohla přesvědčit. Třeba přehledná syntaxe, výborná dokumentace, snadnost a efektivita vývoje, rychlost výsledného programu, bohatost knihoven, snadná distribuce programů a tak dále a tak dále. Mně se Python taky ve všem nelíbil, třeba právě toho povinného odsazování jsem se také obával. Ale svými jinými vlastnostmi mě přesvědčil. Obávám se však, že Lisp žádné takové vlastnosti, které by mě přesvědčily, nemá. Lisp by mě pravděpodobně nezaujal ani kdyby mě nenutil myslet jinak. Podívejte se třeba ne ten seznam GTK bindingů a mrkněte na Common Lisp, to je prostě slabota.
  • 10. 8. 2005 8:50

    Pavel Tišnovský
    O Jythonu vím a abych se přiznal, tak po něm pro jeden projekt se zájmem pokukuji :-). Máte na tom i svou zásluhu v tom, že říkáte, že 2D syntaxe není problém. Opravdu by se mi hodilo mít skriptovací jazyk pro JVM, aby to mohlo koexistovat s dalším kódem na JBossovi. Až bude čas :-(, tak si to určitě vyzkouším.

    Já o Lispu nikoho nepřesvědčuji, ale právě proto mě mrzí, že ho lidé haní, aniž by ho trošku pochopili. Lisp (a další jazyky, například Smalltalk) jsou prostě postavené na jiném paradigmatu, než imperativní jazyky, s tím se nedá nic dělat (teda dá - ignorovat to, stejně jako já ignoruji některé jiné SW výstřelky). Abych pravdu řekl, tak pro mě osobně je to výhoda, že Lisp zná málo lidí - zvyšuje to cenu, kterou si mohu říct za projekt v něm :-) [zatím nejvyšší poměr zaplacená_cena/počet_řádek jsem dosáhl opravdu o Lispu, C-čko bylo s přehledem na posledním místě :-)].

    Snadnost a efektivita vývoje je velmi problematická veličina - pokud Lispovsky nemyslíte (taky s tím mám problémy), tak je to takové neohrabané - prefixový zápis, spousta závorek atd. Na druhou stranu Lisp-guru v něm dokáží udělat fantastické věci, a není to tím, že by používali nějaké extra-mega-for-all-purpose knihovny: i z toho mála, co nabízí standardní knihovna dokážou vytřískat maximum.

    Teda, ono v té std. knihovně toho málo není - (lambda), (map), (apply) apod. jsou velmi mocné funkce a spolu s (cons), (car) a (cdr) a nějakými těmi vstupy a výstupy se dá napsat snad všechno - viz teorie o Lambda kalkulu.
  • 11. 8. 2005 8:29

    Pavel Tišnovský
    Ještě k tomu stylu myšlení: to se mi nechce věřit, že znáte pouze imperativní jazyky :-). Osobně teda nejsem žádný odborník na databáze, ale základy (tabulky, pohledy, table spacy, triggery) v SQL umím, stejně jako prakticky každý, kdo někdy dělal dynamické weby (zmiňoval jste se o PHP, tak Vás řadím do stejné skupiny). Že by práce s DB byla v imperativním Pythonu jednodušší, než nějaký vypečený SELECT ?
  • 11. 8. 2005 9:23

    Petr Mach (neregistrovaný)
    No, jestli to berete takhle, tak znám ještě češtinu :-). Tím chci říct, že SQL nepovažuji za programovací jazyk, i když má i funkce, stejně tak za programovací jazyk nepovažuji třeba xslt. Ale máte pravdu, znám i jeden podivný jazyk a to TeX :-).
  • 12. 8. 2005 8:49

    Pavel Tišnovský
    Pravda, SQL 1 a SQL 2 není Turing complete, na druhou stranu se mu říká 4GL (four generation language). SQL 3 už by mělo být Turing complete, ale těžko říct, z jakého důvodu - na programování to přece má PL/SQL atd.

    TeX je na druhou stranu Turing complete, ale přiznám se, že jsem mu nikdy nepřišel na chuť. Místo psaní programu v TeXu jsem vždycky raději udělal nějaký skript, jehož výsledkem byl LaTeXovský zdroják :-)
  • 12. 8. 2005 8:42

    Pavel Tišnovský
    "Ten jiný styl myšlení je právě to, co se mi na Lispu líbí nejmíň. Dám radši přednost jazyku s normálním stylem myšlení, protože v tom umím myslet a dobře programovat. Za jiný styl myšlení má u mě Lisp mínus. Ale jsou i jiná kritéria, která by mě mohla přesvědčit."

    <Rýpnutí>Přiznám se, že tuto odpověď jsem od Vás (konkrétně od Vás) nečekal. Budete souhlasit s tím, když provedu v předchozím odstavci substituci :s/Lisp/Vim ? Protože i tento zcela jistě skvělý textový editor mě před cca osmi lety donutil zcela změnit styl myšlení i u tak banální věci jako je pořizování a editace textu. A teď jsem tomu rád a nelituji času a úsilí, které jsem do naučení Vimu vložil (začínal jsem někde mezi trojkovou a čtyřkovou verzí).</Rýpnutí>

    Pokud máte čas, mrkněte se na stránku http://www.paulgraham.com/avg.html (Beating the Averages) - nejlépe vytisknout a přečíst si někde v klidu u pivečka:-) Je to opravdu zajímavé čtení a mimochodem Python je tam hodnocen poměrně dobře. Jo Paul Graham patří mezi lidi jako Larry Wall či Guido van Rossum. V tom článku je také zmíněno, proč nemá smysl na pár řádcích ukazovat výhody Lispu - programátor uvyklý na jiný (=méně výkonný :-) programovací jazyk prostě myslí v tom svém jazyku.

    A když už jsem u těch odkazů, doporučuji také http://www.paulgraham.com/diff.html (What Makes Lisp Different).

    Rozumějte mi, já nikoho nepřesvědčuji, aby v Lispu opravdu programoval, ale myslím si, že kdo zná Lisp, bude programovat lépe i v dalších programovacích jazycích. Pravda však je, že pokud bych bral v úvahu pouze to, co nám o Lispu říkali na škole, taky by se mi nelíbil (tam jsme brali pouze začátek, který je krušný). Já jsem měl to štěstí, že jsem dělal v AutoLISPu už od AutoCADu 10 (jel i na mé 286), takže jsem se ho "musel" naučit a také toho, stejně jako v případě Vimu, nelituji.
  • 10. 8. 2005 19:58

    Jakub Hegenbart
    Já jen podotknu, že Common LISP má standard, ten se jmenuje ANSI Common LISP a jeho velmi hutná norma jménem HyperSpec je na stránkách http://www.lisp.org/HyperSpec/FrontMatter/index.html . Je to rozebrané opravdu do mrtě. Až na vlání GC je můj kód čistý ANSI Common LISP, takže by snad s přenositelností neměl být problém. Dokonce makro TIME, kterým měřím čas, je ve standardu (http://www.lisp.org/HyperSpec/Body/mac_time.html#time ). V Cčku by si tím nebyl jistý, co je v knihovně za funkce pro měření času.
  • 11. 8. 2005 9:32

    Petr Mach (neregistrovaný)
    No, po smazáni toho GC se to spustilo, ale bylo to desně pomalé. Ale měl jsem dojem, že se to dá kompilovat (někde jinde píšete že ne), výstupem gcl múže být .c a .h soubor, ale nepřišel jsem na to jak ho zkompilovat. Takže vlastně doteď nemám reálnou představu o výkonu Lispu vs. Pythonu.
  • 10. 8. 2005 19:36

    Jakub Hegenbart

    Ale to si pletete implementaci a jazyk. :-)

    Použil jsem CLISP a CMUCL, což jsou dvě implementace, které se mi dost líbí (CMUCL je výkonnostně možná nejlepší LISP vůbec), a ten benchmark jsem pustil interaktivně:

    CLISP:
    (compile-file "neco.lisp")
    (load "neco.fas")
    nebo CMUCL:
    (compile-file "neco.lisp")
    (load "neco.x86f")

    případně to nějak narvat do parametrů příkazového řádku, ale to jsem zatím nepotřeboval. Ostatně v obou implenentacích se dá aplikace zabalit do image tak, že se po spuštění image ve VM spustí rovnou zadaná funkce, u CMUCL se to snad dá udělat i přímo spustitelné.

    Vybrat si GCL, to je odvaha, tam jsou věci trošku složitější a zatím s ním nemám zkušenosti.

    Jo a samozřejmě je dobré použít správnou cestu k souboru s daty.

  • 11. 8. 2005 8:24

    Pavel Tišnovský
    Ono se o tom asi nesluší moc mluvit :-), ale GNU verze mnoha programovacích jazyků, zejména těch "speciálních" nejsou moc dobré, protože je IMHO píšou mainstream programátoři. Je to problém například u GCL, ale i u GForthu, kde z tohoto vyloženě minimalistického jazyka udělali strašně velký moloch (i když některá rozšíření tam jsou pěkná).

    To samozřejmě neplatí o rodině GCC, ta je velmi kvalitní a mnohdy přesahuje i kvalitu komerčních alternativ.
  • 10. 8. 2005 19:43

    Jakub Hegenbart
    A víte, že v práci nemáme ani jeden počítač s Pythonem? :-) A víte, čím to je? Překvapí vás to: Musí se stáhnout a nainstalovat! ;-)
  • 11. 8. 2005 8:26

    Pavel Tišnovský
    U nás to někteří lidi mají, protože se Python instaloval současně s WinCVS :-) Teda na nic ho nepoužívají, ale teoreticky přes konzoli WinCVS můžou (já tam mám Tcl).
  • 12. 8. 2005 8:52

    Pavel Tišnovský
    Dobře, zvyšuji počet instalací Pythonu o jedničku, protože jsem jediný, kdo OO.org v práci používá :-( Pravda je, že v tomto případě bych byl moc rád, kdyby se počet takto nainstalovaných Pythonů blížil 100%, uvidíme, až vyprší licence na MSDN :-)
  • 12. 8. 2005 8:53

    Pavel Tišnovský
    Stejně si ale rýpnu, když se na tučňákovi podívám do adresáře /usr/share/pygtk/1.2/defs/*.defs, co tam nevidím - Scheme jak vyšité :-)))
  • 12. 8. 2005 15:20

    Petr Mach (neregistrovaný)
    Takže vy skutečně máte binding na GTK1? Co vás k tomu vede? Mimochodem, víte proč ty definice jsou ve scheme? :-)
  • 12. 8. 2005 16:01

    Pavel Tišnovský
    Myslel jsem si, že si toho všimnete:-) Binding mám i na GTK 2, chtěl jsem si otestovat to "zvýšení kvality GUI mezi GTK 1.x a GTK 2", které tady bylo prezentované. V čem je problém, vždyť ty dvě verze knihoven mohou mezi sebou koexistovat bez problémů?
  • 16. 8. 2005 8:20

    Pavel Tišnovský
    Ano, taky jsem nikdy netvrdil opak. Btw, ten problem s modulem se nevyskytl u bindingu k GTK, ja jsem tam pouze uvadel, ze neco jako Lisp (=Scheme) je/bylo defaultne dodavano prave s GTK, takze kdyz rozsireni Lispovskych jazyku neni az tak male. Ale jak jste sam spravne poznamenal, tak knihovny Scheme a ANSI CL nejsou navzajem kompatibilni.

    Mohu mit jeste jeden dotaz? Uvazuje se, zda v dohledne dobe projde Python nejakou standardizacni komisi (ANSI, lepe ISO ci ECMA)? To by myslim Pythonu otevrelo cestu do podnikovych informacnich systemu - mozna se budete divit, ale i takove "malickosti" mnohdy rozhodnou o volbe pro mnohe ucely nevhodneho statickeho jazyka (Java) na ukor jazyku dynamickych (Python, Ruby) a takove rozhodnuti je potom uplatnovano nekolik let (skoleni, nakup vyvojovych prostredku a literatury, ...). [Jestli uz Python necim takovym prosel, tak se predem omlouvam, ale nikde jsem to nenasel.]
  • 17. 8. 2005 15:23

    Petr Mach (neregistrovaný)
    Zajímavá otázka, o formální standardizaci jsem nic neslyšel. Domnívám se ale, že není na pořadu dne, protože by byla omezující, zakonzervovalo by ho to. Na Pythonu je mj. hezké, jak se pěkně a užitečně rozvíjí s každou verzí. Viz. třeba dekorátory ve verzi 2.4.
  • 17. 8. 2005 16:46

    Pavel Tišnovský
    Jasně, já osobně (jakožto programátor) s tím samozřejmě problém nemám, ale například naše vedení s nějakou standardizací počítá i u dalších SW produktů (otázka je, jestli to má nějakou vypovídací hodnotu). Jestli jsem to však pochopil správně, tak C-čková verze Pythonu je považována za referenční a ostatní (PyPy, Jython...) by se jí měly přibližovat (samozřejmě kromě knihoven, teď se bavím čistě o jazyku).
  • 18. 8. 2005 10:17

    Petr Mach (neregistrovaný)
    No, než céčková, tak bych spíš napsal Python co ho vyvíjí Guido van Rossum. Prostě Python z www.python.org. Osobně se domnívám, že by klony měly implementovat i některé knihovny, které jsou v podstatě součástí jazyka, třeba datový typ Decimal nebo Set, které vnímám jako součást jazyka i když nejsou built-in.
  • 29. 7. 2005 14:43

    Pavel Tišnovský
    A bude to v LISPu? Potom by to chtělo kompilátor do bytekódu, aby se ten program zase trošku urychlil. Přecejen čistě interpretované Scheme apod. je trošku pomalé.
  • 25. 7. 2005 11:58

    Pavel Tišnovský
    Teď nemám kde si Lisp vyzkoušet, ale udělal bych několik úprav:

    1. k těm čtyřem seznamům opravdu přistupovat jako k seznamům - tj. append atd.
    2. místo if/else bych použil cond, to je velmi mocná jazyková konstrukce, kterou jsem jinde v této podobě neviděl.

    Je fakt, že pro ne-lispera by to přestalo být čitelné, ale pro někoho zase může být nesrozumitelný ten for cyklus v Pythonu.
  • 29. 7. 2005 19:16

    Keo (neregistrovaný)
    Nedá mi to a přihodím ukázku v mém oblíbeném Erlangu. Je to vlastně samostatný modul s jednou funkcí, provádějící požadovanou operaci.
    -module(trizeni).
    -export([proved/1]).
    
    proved(Vysledky) ->
      Trid = fun ([ true,true,X  ],{ A,B,C,D }) -> { [X | A],B,C,D };
                 ([ true,false,X ],{ A,B,C,D }) -> { A,[X | B],C,D };
                 ([ false,true,X ],{ A,B,C,D }) -> { A,B,[X | C],D };
                 ([ false,false,X ],{ A,B,C,D }) -> { A,B,C,[X | D] } end,
      lists:foldl(Trid,{[],[],[],[]},Vysledky).
    
    Z interaktivního shellu nebo jiného modulu/programu se pak tato funkce zavolá např. takto:
    { AABB,AAB,ABB,AB } = trizeni:proved([true,true,1],[true,false,2],[false,true,3],[false,false,4]]).
    
    A poté mohu s proměnnými AABB apod. dále pracovat. Jména byla zvolena jinak vzhledem k tomu, že v Erlangu musí jméno proměnné začínat velkým písmenem.
  • 23. 7. 2005 8:25

    Petr Mach (neregistrovaný)
    Proste proti tomu ze jej spousta lidi povazuje stale za uzitecne, jednoduche a vhodne i pro zacatecniky nic nezmuzete, to je overeny fakt.
    Nezmuzu, ale mohu ty zacatecniky upozornit na to, ze tomu tak neni.

    zeby zavorkama jak je to bezne u jinych, normalnich, jazyku? ;-)
    Takze se shodnem na tom, ze samotne odsazeni nestaci.
  • 22. 7. 2005 18:23

    Pavel Tišnovský
    Ale proč fanatismem (jsou jiné jazyky, za které se opravdu stojí bít)? Však to, že Python je jednoduchý přece nevylučuje, že i Tcl je jednoduché, ne? Já Python v žádném případě neodsuzuji, jen jsem ve svých příspěvcích upozorňoval na to, že všechno není tak černobílé, jak to může z hlediska implementace dvou toolkitů na jednom OS vypadat. (opravdu to vypadá na souboj toolkitů a ne jazyků).
  • 23. 7. 2005 8:28

    Petr Mach (neregistrovaný)
    To byla reakce na tvrzeni, ze pouzivani dvojtecek na konci podminek je slozite. To nemuze nikdo myslet vazne.
  • 25. 7. 2005 10:21

    Pavel Tišnovský
    Není to složité, je to ale zbytečné rozšiřování funkce různých interpunkčních znamének, takže si programátor musí pamatovat o jedno pravidlo víc. Prostě je to zbytečné a nevím, proč si zrovna Python šel svojí vlastní cestou na nepoužil syntaktické konstrukce známé z jiných programovacích jazyků.

    Představte si situaci, kdyby se v Pythonu všechny bloky označovaly pomocí složených závorek ala C, C++, Java, JavaScript, částečně Tcl, Perl atd. a nezáleželo by na bílých znacích. Šlo by automaticky o horší jazyk? (třeba tím, že by se nedejbože podobal dalším jazykům a nebyl by tak vyjímečný :-).

    Osobně jsem byl vždycky proti takovým "jazykovým buzeracím", například se jednalo o tečku za posledním endem v Pascalu či podmínkami, kdy před else může být středník a kdy ne. A to nemluvím o Fortranu, jehož dřívejším standardem se Python asi inspiroval :-)
  • 25. 7. 2005 17:31

    Petr Mach (neregistrovaný)
    Není to zbytečné už jen proto, že to zvyšuje přehlednost kódu, což je značně pádný důvod. Přehlednost a srozumitelnost kódu je jeden z nejdůležitějších aspektů programovacího jazyka. Také jsem psal, že bez toho byste těžko rozlišil víceřádkové podmínky.

    Python je inovativní jazyk a také zavádí ty nejlepší myšlenky, které se kde objevily, je-li to výhodné a podporuje-li to jeho cíle být snadným, přehledným a efektivním jazykem. Každý jazyk si jde svou cestou a snaží se přinést něco výhodného, za co stojí ho používat, proto různé jazyky vznikají, na tom není nic špatného. Krom toho, Python není první jazyk, který používá dvojtečky na konci podmínek, jestli se nepletu, umí to i PHP jako svou alternativní syntaxi a má to myslím mnohem hlubší kořeny (modula? nechce se mi pátrat). Rozhodně je to srozumitelné a čitelné, dvojtečky se ve stejném smyslu používají i při zápisu lidských jazyků, takže je to pro laika imho intuitivní záležitost.

    Představte si situaci ... Šlo by automaticky o horší jazyk? Ano, bezpochyby šlo. Kdyby Python používal závorky jako C, pak by trpěl závorkovým peklem jako C. Když programátor v jazyce C zapomene napsat závorku a má rozsáhlejší kód s více zanořenými bloky, jazyk není schopen zjistit, která závorka to vlastně chybí, vypisuje nesmyslná hlášení a programátor musí chybu pracně odhalit sám, což začátečníkům dělá potíže, vzpomeňte si na své studenty VBA, že by to museli řešit (nemusí VB také nepoužívá závorky). Python oproti tomu chyby lokalizuje přesněji, čímž programování dělá rychlejším a efektivnějším (efektivnost = náklady = cena produktu). Krom toho závorku na konci bloku v něm nemůžete zapomenout napsat, tuhle zbytečnost Python odboural.

    Osobně jsem byl vždycky proti takovým "jazykovým buzeracím" Považujte za buzeraci nutnost psát závorky a rázem si Python oblíbíte :-). Ušetří vás třeba také psaní středníků na konci příkazů, další kratochvíle začátečníků. Věřte, že Python tohle všechno zavedl proto, aby ulehčil práci progrmátorům, nepro efekt, aby se odlišil.

    Python se inspiroval řadou známých i neznámých jazyků, vytáhl z nich ty nejlepší myšlenky a přetavil je do kompaktní podoby, do podoby jazyka Python.
  • 26. 7. 2005 8:11

    Pavel Tišnovský
    Ve VBA je to ještě více zprasené, buď se podmínka napíše na jeden řádek, nebo se musí rozdělit na řádků více a použít k tomu další interpunkční znaménka. A to vůbec nemluvím o zápisu řetězců přes více řádků - prostě tím, že do jazyka vložili konec řádku jako znak se speciálním významem to všechno dost zkomplikovali. V žádném případě nepovažuji VBA za ideální jazyk, jediné, co se mi na něm líbí, je variabilní zápis smyček a "operátor" mid$ :-)

    K dvojtečkám mám prostě tu výhradu, že se musí používat současně s odsazováním. Takže jedno nebo druhé je tam navíc a to proto, že chybí znak/slovo pro konec bloku. Ale uznávám, že jde pouze o zvyk a Tobě to může vyhovovat (a zcela jistě to vyhovuje i dalším lidem, jinak by se Python nepoužíval a nahradilo by ho, teď plácnu, například Ruby). Jo, dvojtečky se opravdu používají, ale v mnoha jazycích mají význam oddělovače pro label (obvykle cíl pro nepodmíněný skok, slavné GOTO), což opravdu do nových jazyků nebudeme zavádět :-)))

    Se středníky na konci příkazů jsem se opravdu nikdy moc nesžil (LISP ani Tcl je nemá :-). Zajímavé je, že ony by možná nebyly zapotřebí ani v C-čku (stejně jako závorky u podmínek a smyček), přinejmenším ne v takové míře. Musím se nad tím zamyslet, ale překladač to při syntaktické analýze opravdu nemusí potřebovat.
  • 26. 7. 2005 15:10

    Petr Mach (neregistrovaný)
    Tak ja rozhodně nechci hájit VB, protože to je jeden z nejhnusnějších jazyků co jsem kdy viděl. Jen jsem chtěl ukázat, že to není tak, že všechny jazyky používají závorky a jen Python odsazování a když vím, že znáte VB, tak jsem poukázal právě na něj. Existují různé způsoby jak definovat strukturu dokumentu a závorky jsou zrovna dost problematické.

    Dvojtečka není navíc. Dvojtečka říká tady je konec podmínky a odsazení říká, tady je blok příkazů. Příkaz podmínky může být víceřádkový a odsazený stejně jako blok příkazů, takže ten konec poznáte jen podle dvojtečky. Na tuhle skutečnost jsem již upozorňoval a nehodlám ji pořád dokola opakovat.

    Význam dvojtečky jsem zmiňoval u LIDSKÝCH jazyků, kde má podobný význam jako v Pythonu, tedy názorně:
    Franto, nezapomeň koupit:
        půl chleba
        litr mléka
        deset vajíček
    
    Čistě teoreticky tam ta dvojtečka taky být nemusí, stačí odsazení, ne? Jenže typografie (obor zabývající se předávání informací písemnou formou co nejsrozumitelnějším způsobem), která se vyvíjí po staletí dospěla k tomuto řešení, bez dvojtečky by to bylo málo přehledné. Takže i kdyby ta dvojtečka tam teoreticky nepotřebovala být, tak tam být musí, aby kód byl přehledný a čitelný, na což se u Pythonu klade důraz.
  • 26. 7. 2005 16:19

    Pavel Tišnovský
    No vidíte, v názoru na VB (a Vim) se shodneme :-). Určitě se dá zvyknout i na tu dvojtečku a odsazení. U oběda jsem si na toto téma četl článek od Erica Raymonda (to je ten, co šmelí v bazaru :-) a ten taky měl ze začátku s tímto rysem jazyka problém, takže se nemůžete divit i obyčejnějším lidem, že jim to nevoní.

    Mimochodem, v typografii jsou všechna ta typografická znaménka poměrně nová, v minulosti se bez nich kupodivu obešli. Ten seznam bych spíš napsal ještě s odrážkami (oblíbená kule - bullet), ale to snad žádný programovací jazyk ještě nepřevzal :-)

    Opravdu by nebylo na škodu sepsat článek na téma "Přechod k Pythonu". Na webu je toho hodně, to ano, ale vždycky se tam pouze s velkým nadšením popisují nové a skvělé vlastnosti jazyka nebo jde o jakousi příručku. Zatím jsem nenašel nic, co by mě, jakožto "znalce" celé řady jiných jazyků (Basic, Forth, 6x assembler, Pascal, C, C++, Java, JavaScript, LISP, Tcl, VBA) přesvědčilo o té vyjímečnosti. Samozřejmě dnes nejde jenom o jazyk, ale také - a to mnohdy především - o dostupné knihovny a další podpůrné prostředky (IDE, make, tvorba dokumentace) - v tomto ohledu vypadá Python dobře.
  • 23. 7. 2005 3:45

    Jakub Hegenbart

    Python v žádném případě není jednoduchý. Jediné jednoduché jazyky, které znám jsou Lisp, Scheme, FORTH, Smalltalk, Self a případně i TCL, i když ty na začítku seznamu vedou.

    Čitelný bloatware je pořád bloatware. Nic proti tomu, že je to snadno naučitelný bloatware (mám Python rád, stejně tak i Ruby), aspoň má výhody oproti megabloatwaru s názvem „C++“, který má z mého pohledu nejhorščí poměr bloat/užitečnost v celé historii programování, ale pořád jím zůstává.

  • 23. 7. 2005 8:39

    Petr Mach (neregistrovaný)
    Python v každém případě je jednoduchý, ale chápu co se snažíte říct. na jednoduchost se lze dívat z různých stran. Např. používat rýč je jednoduší než traktor, ale zorat pole je jednoduší traktorem než rýčem. Takže své tvrzení upřesním.

    Současný Python je jazyk jednoduchý na pochopení, snadný na používání a vhodný pro začátečníky. O kterém z vámi jmenovaných jazyků lze tvrdit to samé? A to upozorňuji, že dřív jsem se k Pythonu tak pozitivně nestavěl.
  • 23. 7. 2005 9:01

    Jakub Hegenbart
    No, Forth má jistá temná úskali a jakožto zesilovač programátora by k začátečníkovi asi nebyl moc příjemný. Ale myslím, že Lisp a Smalltalk jsou docela příjemné jazyky, Smalltalk je pak obzvláště názorný. Já jsem se Python začal učit, ale

    Asi to je o osobním cítění a hlavně o myšlenkových pochodech jedince, které jsou lépe nakloněny tomu či onomu jazyku a jinému třeba hůře...

    Já prostě zjistíl, že jsem nakloněný jazykům jednoduchým, ale od základů rozšiřitelným. Všechny tři jmenované tyhle vlastnosti mají a přijdou mi jako opravdu univerzální a přitom snadno použitelníé nástroje (nebo přinejměnším jako nástroje s maximálním poměrem funkčnost/přímočarost).

    Jak říkám, Python je výborný, Ruby ještě lepší. Jen by potřebovaly rychlejší implementace, pak by bylo možné začít v nich psát skoro všechno. (A že to jde, dokazuje třeba Self a CMUCL. ;-))
  • 23. 7. 2005 9:04

    Jakub Hegenbart
    Ach jo, nedopsaná věta: Já se Pyrhon začal učit, ale časem jsem dospěl k názoru, že je tam pro mně trošku moc nepravidelností... :-) (Ale jak říkám, C++ asi v tomhle směru zůstane nepřekonatelné... ;-))
  • 24. 7. 2005 16:33

    nxt (neregistrovaný)
    V Pythone som nic zasadne nerobil, tak ma skludom oznacte za zaujateho.
    V TCL som kvoli skole potreboval robit a po preklikani jedneho tutorialu a najdenia refencnej prirucky som bol schopny v tom robit. Takze potvrzdujem, ze TCL sa da naucit za par hodin. Pacilo sa mi na nom to, ako jednoducho je navrhnuty. Prikaz + parametre, nic viac.

    Z toho co Pythone viem mu upieram prave tu snahu o "citelnou syntaxi". Whitespace ma aj iny syntakticky vyznam ako oddelovac a to je IMHO zla vec. Vo vsetkych pocitacovych jazykoch (okrem Makefilu :), s ktorymi som sa stretol, ako aj v pisanej forme "ludskych" jazykov" sluzi whitespace ako oddelovac jednotlivych elementov jazyka. Medzera medzi slovami, riadok medzi odstavcami. V TCL (alebo Lispe) oddeluje "prikaz" od "parametrov" (uvodzovky kvoli Lispu, pretoze tam to nie je tak podelene). Podobne aj v shelli.

    Jedine v Pythone nesie informaciu o "vnorenosti" blokov. Takze za medzerou, nicim, sa skryva dolezita informacia. A to je IMHO zle. Na zatvorkovanych jazykoch je koniec bloku explicitne vidiet. V Pythone je to implicitne a clovek si to musi domyslat. Preco? Preco ma programator sluzit jazyku, nie jazyk programatorovi? IMHO je to rovnaka prasarna ako implicitne premenne v Perle.

    BTW - skuste si predstavit, ze z dovodov, ktore neovplyvnite (zakaznik, sef-obchodnik, a pod.) dostanete listing programu v proporcionalnom pisme. Zatvorkovy jazyk bude urcite citatelnejsi ako whitespacovy.

    Co sa tyka upravy programov v jazykoch, ktore to nevyzadaju - stabna kultura sa vzdy da zariadit. Pre Linuxovy kernel je stabna kultura pre C. Pre Lisp existuje odporucanie (ktore aj ucia na skolach :). A tiez existuju nastroje, ktorymi si to kazdy moze upravit do "jeho" formy. Pythonovsky "jediny spravny zapis" mi trochu pripomina starsiu slovensku pesnicku o tom, ako budeme vsetci pisat iba modrym perom...

    Zastancom whitespacu odporucam http://compsoc.dur.ac.uk/whitespace/ :))
  • 25. 7. 2005 7:43

    Petr Mach (neregistrovaný)
    V podstatě správné myšlenky, ale chybné závěry.

    Strukturu programu lze definovat různými způsoby, třeba závorkami nebo odsazením. Dovolím si tvrdit, že je to naopak než tvrdíte. Odsazení je čitelnější a je vhodné pro člověka. Proto programátoři odsazují kód i když nemusí. Závorky jsou pro jazyk a jsou samy o sobě nečitelné. Podle nich se programátor těžko orientuje a strukturu programu si musí pracně domýšlet. Jasným důkazem je opět to, že programátoři kód odsazují. Kdyby to bylo jak tvrdíte, nedělali by to, stačily by jim ty závorky.

    Takže programátor sám pro sebe kód odsazuje, aby se v něm vyznal. Závorky používá jen kvůli tomu, že to chce jazyk. Používá tedy dvojí způsob definice struktury programu, jeden pro sebe, jeden pro jazyk. A je tu vámi vznesená otázka, proč se má programátor podřizovat potřebám jazyku? Proč by s jazyk nepřizpůsobil potřebám programátora, není to snad možné? A Python ukazuje, že to je možné, že lidsky čitelný přístup definování struktury programu stačí.

    Co se týče proporcionálního fontu, je to od základu chybná úvaha. Obrázek snad napoví:
    http://wraith.iglu.cz/python/ukazky/gui.checkbox/py-prop.png

    Jestli ne, tak si uvedomte, ze odsazovani se tykaji jen mezry na zacatku radku a ty jsou vsechny stejne siroke, nasledna promenliva sirka znaku na to nema sebemensi vliv.

    Python nema jediny spravny zapis. Python ma pouze povinne odsazovani definujici strukturu programu.
  • 25. 7. 2005 14:11

    nxt (neregistrovaný)
    S tym proporcionalnym pismom to bol blby priklad, uznavam. Python nema jediny spravny zapis. Python ma pouze povinne odsazovani definujici strukturu programu. A to je presne to, o com som hovoril. Python dava programatorovi nieco za povinnost. Programator teda musi plnit ocakavania jazyku o tom, ako ma byt program odsadeny. Zatvorky maju aj tu vyhodu, ze sa da jednoducho skakat zo zaciatku bloku (otvaracia zatvorka) na koniec bloku (ukoncovacia zatvorka) - prikaz vo Vim, defaultne mapovany na '%'. Mozno to funguje aj pre Python - neskusal som. V kazdom pripade viem, ze to funguje na zatvorky a povazujem to za plus. A to je aj to povinne modre pero. V C odsadzujem, lebo chcem. V TCL odsadzujem, lebo chcem. V Pythone odsadzujem, lebo musim. Rozdiel medzi "chcem" a "musim" je dufam jasny. Bohuzial ste nereagovali na ten bod mojho povodneho prispevku - syntakticky obsah white-spacu. Kedze som zatial nepocul ziadne padne argumenty, preco by white-space mal mat aj iny syntakticky vyznam ako oddelovac, tak zastavam nazor, ze by ho mat nemal. White-space == oddelovac prvkov jazyka a nic viac. Odsadenie != oddelenie. "Pretazenie" whitespacu je to, co sa mi na Pythone nepaci. Povinne odsadzovanie s tym len suvisi.
  • 25. 7. 2005 15:30

    Petr Mach (neregistrovaný)
    A to je presne to, o com som hovoril. Python dava programatorovi nieco za povinnost. Programator teda musi plnit ocakavania jazyku o tom, ako ma byt program odsadeny.

    Presne to plati o zavorkach, Programatorm musi plnit ocekavani jazyku o vkladani zavorek.

    V C odsadzujem, lebo chcem. V TCL odsadzujem, lebo chcem. V Pythone odsadzujem, lebo musim. Rozdiel medzi "chcem" a "musim" je dufam jasny.

    V C musíte používat závorky, v TCL musíte používat závorky, v Pythonu nepoužíváte závorky na vyznačení struktury programu. Rozdíl mezi musíte používat a nepoužíváte je doufám jasný.

    Ale, ono je to ještě horší. V C závorky nemusíte používat pouze teoreticky. Prakticky je používat musíte, buď proto že to máte nařízeno (vývoj kernelu) nebo proto, že se v tom programu za pět minut budete chtít ještě vyznat. Odsazování je nezbytnost, takže prakticky v C musíte jak odsazovat tak i používat závorky. Prohlídněte si zdrojáky programů a uvidíte, že to tak je.

    A to stále není všechno. Závorky jsou problematické a nepřehledné, začátečníkům dělají potíže, protože stačí jednu někde zapomenout a máte problém, problém který se těžko hledá. Takže to ještě navíc snižuje efektivitu programování. Proto řada jazyků, jež se snaží být uživatelsky přívětivé závorky nepoužívá a místo nich (třeba bash) používá klíčová slova, nejlépe u každé konstrukce jiné. Nebo, v případě Pythonu, elegantní a ideální (protože stejně musíte) odsazování. A to je aj to povinne modre pero.

    Modré pero odsazování, bílé pero závorky, zelené pero klíčová slova. Nevyberete si. Vždycky něco musíte, vždycky něco máte předepsáno. Akorát že to bílé pero ještě obtahujete tím modrým, abyste něco viděl, dvojí práce to je.

    Kedze som zatial nepocul ziadne padne argumenty, preco by white-space mal mat aj iny syntakticky vyznam ako oddelovac, tak zastavam nazor, ze by ho mat nemal.

    To jste asi nečetl pozorně. Vysvětloval jsem, v čem je výhodnější používat odsazování místo závorek. To je ten důvod. Můžete zkusit vysvětlit, proč "zastavam nazor, ze by ho mat nemal", když je to zjevně výhodné a všichni programátoři, ať na tom ten jazyk staví nebo ne, používají prázdné znaky k odsazení.
  • 22. 7. 2005 15:35

    Petr Mach (neregistrovaný)
    Mate pravdu v tom, ze RAD nastroje cloveku ktery se chce naucit dobre programovat do ruky nepatri, ze musi zacit od zakladu, ale to muze v pripade GUI aplikaci ucinit s jakymkoli toolkitem, to ze pro ostatni toolkity existuje nejaky RAD nastroj neznamena, ze jej musim pouzivat. Jak jsem predvedl, GTK se v Pythonu pouziva snadneji a intuitivneji nez TK v TCL.

    Vzhled programu je dulezity, ale ja si u GTK pochvaluji takove veci, jako snadna tvorba uzivatelsky privetivych programu, vyborna pristupnost pro ruzne postizene a podobne, coz jsou veci, ktere zajistuje prave toolkit a ktere GTK narozdil od TK resi a usnadnuje.

    Ad na velmi jednoduche veci TK a narocnejsi GTK. Zni to na prvni pohled rozumne, ale na ten druhy. Proc pouzivat na jednoduche veci TK, kdyz, jak jsem ukazal, je lze stejne jednoduse udelat s GTK? Relativni snadnost tvorby GUI uz neni jen domenou TCL/TK jako driv. Toolkity jsou vcelku rozsahle knihovny, proc se zbytecne ucit dve ruzne?

    A GTK je podporovano radou jazyku: http://www.gtk.org/bindings.html
  • 22. 7. 2005 15:12

    Petr Mach (neregistrovaný)
    4) Nejsem naivni a presto si to myslim, tento postup je totiz v pripade Python/GTK vyrazne jednodusi a mene namahavy, coz je vec na kterou zacatecnik slysi.

    5) Neni potreba nastavovat kazdou aplikaci zvlast, staci to nastavit jednou pro vzdy po instalaci GTK. Ja jsem si dosud nevsiml, ze by nekomu defaultni vzhled GTK vadil. Pokud se jeste najde nekdo jako pan Tisnovsky, velmi jednoduse si vzhled GTK aplikaci muze prizpusobit, coz je to, o co tu jde.

    Toolkitu mozna existuje spousta, ale tech obecne pouzitelnych a multiplatformnich zas tolik neni. Jakym zpusobem GTK vyzaduje jiny styl prace?

    6) Smyslu te vety jsem presne neporozumel, ale TK pouziva treba defaultne Python. Kdyby TK byl skutecne na urovni modernich toolkitu, nic jineho by se v pripade Pythonu nepouzivalo, protoze u vsech ostatnich toolkitu je nutno zabezpecit distribuci prislusne GUI knihovny s programem, coz jsou zbytecne starosti navic. Pres tuto jasnou vyhodu se TK v Pythonu moc nepouziva, duvody proc tomu tak je jsem uvedl.

    Ad Zaver) TCL/TK jiste bude jeste dlouho zit, pocitace ZX Spectrum take jeste ziji. Ale vhodny pro zacatecniky neni ani nahodou :-), to je hodne zaslepene tvrzeni.
  • 21. 7. 2005 14:14

    Pavel Tišnovský
    1. Dobře, spustitelné to bude až po přidání těch cca třech až pěti řádků (podle toho, co všechno se u nového okna nastavuje).

    2. Podle mě to řešení není ani jednoduché ani složité - prostě je trošku jiné.

    3. Vypadá to, že nebyla zcela zkopírována ta funkce tisk (pokud se při copy&paste nevybere i prázdný řádek pod tím, zapomene se na závěrečný Enter). Ale to není problém toho programu, spíš chování Wishe, který potřebuje mít příkazy po zadání odEntrované (taky se mi to párkrát stalo když jsem mezi Wishem a textovým editorem něco přenášel). Ostatně takto se chovají prakticky všechny shelly, Wish akorát způsobuje to, že se dané okno vykreslí ihned, takže to vypadá, že program je již hotov.

    4. Začátečníci ani neví, co je to pole, věřte mi. Tady mám možná tu praktickou výhodu, že jsem už mockrát školil Word a Excel (pokročilý kurz). Tam se samozřejmě došlo na makra a VBA. Ty lidi z kurzu ještě tak pochopí, co je to proměnná, dokážou napsat podmínku a smyčku - toť vše, nic jiné nepotřebují pro svoji práci vědět (samozřejmě něco okolo objektů VBA). Zkoušel jsem vysvětlovat datové typy, pole, struktury - to pro napsání jednoduchých skriptů opravdu nepotřebujete. Nemějte to těm lidem za zlé: mě když přestala jet švagrova Vectra, taky jsem na to čuměl jako puk a nebyl jsem s tím schopen nic udělat (a to znám funkci motoru a jeho částí docela dobře).

    5.

    a,b) A to je právě ten problém: GTK může Windows napodobit, ale v žádném případě to není WinAPI (ještě víc mě to vadí u Swingu, který se také Windows snaží napodobit). Prostě je to pořád napodobenina, která se chová jinak, než klasické Windows programy. A GTK opravdu umí antialias fontů, tj. ClearType (nemám teď na mysli rozmazání nebo různé napodobeniny ClearType, které z písma dělají spíš duhu)? Opravdu mě to zajímá, určitě bych to využil.

    c) to bylo moje první seznámení s GTK na platformě Windows. Chtěl jsem uživatelům v práci nainstalovat GIMP, aby také něco měli z OS. Dopadlo to (z hlediska mého času) docela katastrofálně - všechna písma byla malá, v nastavení programu to nešlo změnit a docela dlouho jsem hledal, ve které konfiguraci se toto nastavuje.

    d) antialias fontů samozřejmě funguje na Windows (používají se widgety z WinAPI), na Linuxu ne (tam ostatně nefunguje pořádně nikde, což mě teda hodně vadí a také díky tomu prakticky pořád zůstávám v textovém režimu).

    e) já to myslel tak, že se po instalaci Linuxu (teď je asi jedno, jaká je to distribuce) většinou nastavení GUI upravuje (skiny, chování oken atd.) podle uživatelova naturelu. Nebylo to myšlené jako nějaká urážka, ostatně to stejné dělám v práci i na XP-čkách (tj. vracím to zpět od té modré hrůzy k tématu Windows 2000 :-)

    f) nebyl by nějaký příklad? Mě teď napadá například (když se dívám na pracovní počítač): bez rozdílu vše z Javy, OpenOffice.org 2 beta (doufám, že to změní) a Lotus Notes (to je kapitola sama pro sebe). Všechno ostatní dodržuje konvence: komerční programy veskrze (spíš základní GUI rozšiřují), ale i například GVIM (ten také chování rozšiřuje o "odtržitelná" menu). Nevím, proč by dodržování konvencí daného UI mělo být pro Tk nějaký problém.

    6. jasně, souhlasím. Nicméně si stále myslím, že ten seriál o Tcl/Tk má smysl a tento jazyk a toolkit v žádném případě nepatří do důchodu.
  • 21. 7. 2005 18:53

    stefan (neregistrovaný)
    5f) Z toho co mam napocitaci: Norton Antivirus a Lavasoft Ad-aware. Vyzeraju ako omalovanky. User zvyknuty na menu a toolbar ma co robit, kym sa v tom zorientuje.
  • 22. 7. 2005 9:01

    Pavel Tišnovský
    Pravda, tyto dva softy (sam je nevlastnim) jsou jak omalovanky (z teto kategorie me napada jeste Personal Firewall, kde clovek take nevi, co kde namackat). Osobne jsem se neorientoval napriklad ani v ceskem AVG. U jednoho uzivatele jsem chtel nastavil aktualizaci ze souboru (nikoli ze site) a v menu a dalsich dialozich jsem to zaboha nemohl najit. Nakonec se ukazalo, ze je to dostupne pouze z hlavniho okna pomoci ikonky, ktera vsak nebyla zobrazena, pokud bylo okno male (tj. v defaultni velikosti)!

    Naopak takovy McAfee VirusScan je klasicka okenni aplikace a umi toho (pri nasazeni na siti) opravdu hodne, takze na GUI moc nezalezi.
  • 22. 7. 2005 16:24

    Petr Mach (neregistrovaný)
    1) Netvrdím že ne, tvrdím že tak jak to je, to je nekompletní. Souhlas?

    2) Odmítáte to vidět, odmítáte přijmout fakta. Projev fanatismu? V každém případě taková debata nemá smysl.

    3) Aha, takže při kopírování kódu má problém TCL a ne Python, zajímavé, což?

    4) Uživatelé programu Word jsou úplně jiná kategorie lidí než programátoři, kteří se začnou učit TCL nebo Python a osobně jsem přesvědčen, že takové lidi spíš naučíte Python než TCL, z kterého budou velmi zmatení. Nebo snad svůj seriál cílíte na uživatele Wordu? Asi těžko.

    5) ab) I.) To není žádný problém, rozdíly GUI mezi jednotlivými verzemi windows jsou podstatně výraznější. Ostatně, podívejme se na možnosti skinu Wimp na jedné GTK aplikaci pod různými verzemi windows:

    http://gtk-wimp.sourceforge.net/screenshots/

    Myslím že vaše znalosti GTK jsou dost kusé a přdevším z doby raz dva (rozuměj GTK verze 1, které je dávno pasé). Prohlašuji odpovědně, že ani běžní a ti nejprostší uživatelé Windows s GTK nemají žádné problémy. Uživatele mnohem více mate a rozčiluje např. podivuhodné chování Excelu XP, kdy se jedno okno tváří (v taskbaru) jako dvě a omylem si tak zavírají dokumenty které si zavřít nechtějí.

    5) ab) II.) Co se týče fontů. tak ano, GTK podporuje technologii vyhlazování fontů. Jestli jste si toho ještě nevšiml, tak si znovu prohlédněte tento screenshot: http://wraith.iglu.cz/python/ukazky/gui.checkbox/gtk-tk.png

    ClearType to není, přinejmenším na Linuxu, protože to je patentovaná technologie, ale to nevadí, použitá technologie je kvalitní, používá se služeb knihovny freetype a je hezky nastavitelné: http://www.hugis.org/pic/font-rendering-details.png

    Oproti tomu řada lidí vyhlazování fontů ve windows upřímně odsuzuje. http://www.pixy.cz/pixylophone/2005_03_archiv.html#1111622542

    Že na tom něco je ukazuje i fakt, že ve Windows se malé písmo (rozuměj to, co běžně vidíte na obrazovce) pro jistotu nevyhlazuje, v linuxu ano. Já často přecházím mezi Linuxem a Windows a GUI Windows mi přijde primitivně hrubé a zubaté. Ve windows možná GTK nepoužívá freetype, ale služeb systému, tedy to kritizované ClearType, to nevím. Vyzkoušejte a dejte mi vědět.

    c) V nastavení gimpu lze vybrat téma s větším a menším fontem. Ale pár příspěvků napřed jste si stěžoval, že GTK má font příliš velký, jak to tedy je? :-) Mám čím dál větší pocit, že protestujete jen proto abyste protestoval bez řádných zkušeností a znalosti faktů.

    d) To je sprostá pomluva nezakládající se na pravdě, je to přesně naopak, viz text o kousek výše. Ale shodneme se na tom, že TK je na Linuxu vypadá fakt hnusně a nikdo ho tam nemá rád.

    e) Ne, já nemám tu potřebu, pouze místo Gnome poižívám lehkotonážní IceWm, na vzhled widgetů to nemá žádný vliv.

    6) Ano, smysl má, vždyť jsem to uvedl hned na začátku, je fajn se podívat na primitvní kořeny moderních jazyků a gui toolkitů :-). Jen jsem na to upozornil nezkušené zájemce o programování, protože z článku to tak nevyznělo.
  • 22. 7. 2005 18:19

    Pavel Tišnovský
    1) Ano, souhlasím, ten příklad nebyl na 100% stejný, jako Tvůj.

    2) Já nevím, co je jednoduché a složité je přece věc individuální. Já mám například problém přečíst některé skripty v Perlu i když jsou (pro jejich tvůrce) jednoduché. Na druhou stranu můžu zbastlit něco v assembleru nebo v LISPu a mě to, narozdíl od mých kolegů, přijde úžasně jednoduché a v případě LISPu i elegantní.

    3) Ale to není problém Tcl, prostě jsi na posledním řádku nedal Enter a tak ta funkce celkem logicky vůbec v tom programu neexistovala. Kdybych dal definici funkce hned na začátek programu a na konec až například pack pro nějaký button, tak bys ten button neviděl a hned by Tě to trklo.

    4) Třeba takový bastlič, co si chce zjednodušit vytváření GUI ke svým skriptům může být jeden z cílových uživatelů Tcl/Tk. Uživatelé programu Word/Excel, kteří si pro sebe (nebo např. pro svou pracovní skupinu) píšou makra jsou podle mě na úplně stejné úrovni, i když k tomu programování přistupují "zvrchu", tj. neví nic o vnitřnostech (a kdo z dnešních bastličů ví?, to je přece celkem normální, když jsou dnes počítače tak složité).

    5) Asi ano, moje zkušenosti s GTK 2 jsou především uživatelské, s GTK 1.x jsem dělal i několik aplikací (ale bylo to čisté C-čko). Na uživatelské úrovni mají někteří lidé s GTK 2 problémy, například se to týká standardních dialogových oken atd. S Excelem XP máš naprostou pravdu, taky mi to přijde nelogické (a k tomu je mi to naprosto jedno, tento software nepotřebuji).

    Fonty) Ano, GTK podporuje vyhlazování fontů. Měl jsem na mysli ClearType, to co se používá v Linuxu, je tomu hodně vzdálené (pravda, můj notebook i externí LCD displej připojení k běžnému PC může mít vadu, že tato technologie funguje pouze v XP :-) - podotýkám, že jsem zkoušel všechny barevné kombinace subpixel antialiasingu). Jestli se to někomu v XP nelíbí, může si to vypnout.

    Jo, které písma (TrueType) nejsou v XP vyhlazena? Osobně mi GUI zobrazuje vše ve velikosti osm bodů (hodně malé) a vyhlazené to je. O velkých fontech v GTK jsem nemluvil (nebo jsem se špatně vyjádřil). Fakt je ten, že po instalaci na Windows GIMP vše zobrazoval strašně malým písmem, které sice v jeho nastavení šlo zvětšit, ale pořád to bylo málo. Proto ten zásah do konfiguráku.

    d) Já teda nevím, ale když mi v prohlížeči kolem písma poblikávají zelené, červené a modré pixely, tak to za moc kvalitní antialias nepovažuji. Ale jak jsi sám říkal, někomu se to nelíbí vůbec, tak si to vypne (já to mám také na Linuxu vypnuté).

    e) ok, souhlas. Sice místo IceWm mám Fluxbox, ale to je opět pouze otázka vkusu (a také zvyku).

    6) primitivní kořeny :-) Fakt je, že moderní programovací jazyky se stále ještě přibližují možnostem stařičkého LISPu, takže z historického hlediska na tom Tcl a Python bude za cca pět let asi tak stejně: Tcl už nikam níž spadnout nemůže - ti co poznali jeho kvality ho budou dále používat a Pythonu trošku klesne ta jeho dnešní popularita a "modernost" :-) I když s tou popularitou to už nebude tak slavné, dneska jsem byl v knihkupectví a o Pythonu tam byla jedna (kvalitní) knížka, ostatek byl Perl (2 tituly), Flash (2 tituly), JavaScript (cca 10), Delphi (také tak), C, .NET a Java (hafo). Ale to je úplně OT, jen bych se tak neoháněl tou primitivností.

    ps: trošku se to tady zvrhlo, jestli seš někde z okolí Brna, zvu Tě na pivčo.
  • 22. 7. 2005 19:47

    earl365 (neregistrovaný)
    Hmm.. Ja len k tomu Gtk+ na windows. Pouzivam pod XP ckom gimp 2.2, original instalator (exe), Takisto Gtk+ 2.6.8.
    http://gimp-win.sourceforge.net/
    Pouziva sa defaultne gtk-wimp, systemovy font (tahoma), clear type funguje uplne bez problemov (na tej stranke je aj screenshot, pekne to vidno)
    Takze co sa tyke Gtk+, v podstate je potrebne len dobre nastavenie (ktroe uz niekto spravil za nas :))
    Horsie je to trochu s prekreslovanim, tam je vidno rozdiel oproti x window verzii.
  • 23. 7. 2005 9:58

    Petr Mach (neregistrovaný)
    2) Ano, na základě různých zkušeností se u věcí s přibližně stejnou složitostí může zdát jednomu jednodušší to a druhému ono. To však nebrání obecnému zhodnocení složitosti věcí s výrazně různou složitostí. Obecným zhodnocením rozumějte zhodnocení oproštěné od vlastních znalostí a zkušeností. Např. já teda znám asm, tak mi to přijde jednoduché, ale vím že jsem se ho učil rok, a tady o TCL si myslím že se dá naučit za den, takž je určitě jednodušší.

    Co se týče Perlu, tak ten především umožňuje dost nečitelný zápis.

    3) Já jsem podle návodu zkopíroval zdroják a prostě to nefunguje, skoušel jsem to několikrát. Jestli to je chyba TCL nebo ne nevím, ale vím, že jste jako nedostatek Pythonu označil možné problémy s kopírováním jeho zdrojáků.

    4) Takže budeme-li mluvit o bastliči a ne programátorovi, co mu TCL/TK přinese oproti Python/GTK? Nedá takový bastlič radši přednost klikacímu RAD nástroji?

    5) Vím že některým lidem se nelíbí dialogové okno pro výběr souboru, protože jsou zvyklí na jiné, ale problémy s ním nemají. Zde je nutno upozornit, že tento dialog se mění i v rámci různých verzí windows a nikdo si nestěžuje na to, že by s ním měl problémy. Shodneme se tedy na tom, že uživatel Windows je vystavován výrazným změnám GUI i v rámci produktů Microsoftu a GTK nijak nevybočuje z toho, na co je zvyklý.

    Fonty) Souhlasím s tím, že vyhlazování co se používá v Linuxu je hodně vzdálené Clear Type, je hodně napřed. Viz odkaz na hodnocení Clear Type, co jsem vám dal. Já vyhlazování v Linuxu používám na LCD i CRT a nemám s ním nejmenší problém a zcela určitě v tom nejsem výjimka. Jestli vy ho máte, možná byste měl aktualizovat svůj systém nebo hledat chybu jinde (ovladač graf. karty?).

    Já používám převážně W2k, kde písma běžné velikosti vyhlazena nejsou, až budu mít příležtost, podívám se na stav WindowsXP.

    d) To je váš individuální problém, který má příčiny kdoví kde, není to obecný jev.

  • 25. 7. 2005 10:12

    Pavel Tišnovský
    5) Mě osobně se například to GTK okno líbí, ale "běžným" uživatelům už ne. Oni mají problém (a to někdy dost podstatný) i například s předchodem od Windows 98 do Windows XP, i když se tam toho změnilo dost málo (v porovnání s dialogem GTK). Když si porovnám Open dialog z Windows 95/98 a z Windows XP, jsou tam tyto rozdíly: trošku jiné ikonky (stále se tam však vyskytuje přechod na .. a vytvoření nového adresáře) a v levé části se nově objevuje ikonový kontejner. Jinak jsou ty dialogy naprosto stejné: v horní části "Oblast hledání" a základní ikonky, uprostřed místo pro výpis adresáře, dole editační pole "Název souboru" a "Soubory typu" no a napravo tlačítka "Otevřít" a "Storno".

    Fonty) Když se bavím o ClearType, mám na mysli především antaliasing pro LCD, pro CRT to je kontraproduktivní technologie. Klasické vyhlazování samozřejmě funguje i v Linuxu (teda, spíš v X.org), ale "pravé" ClearType (ať to již nazveme jakkoli) už není tak dokonalé a proto ho mám vypnuté.

    O problému ClearType W2k jsem našel následující odpověď: http://answers.google.com/answers/threadview?id=6245

    Ono i v XPčkách nejsou všechny fonty vyhlazeny, funguje to totiž "pouze" na OpenType a TrueType fonty (o PostScriptových písmech nevím). Pro rastrová písma není tato funkce celkem logicky k dispozici, což mě mrzí zejména u FixedSysu.

    Jak jednoduše vyzkoušet ClearType: nejprve ho povolit, potom v "Malování" vytvořit truecolorový obrázek a napsat do něj nějaký text. Po zvětšení se na okrajích objeví barevné pixely (text je černý) a o tom to právě je - že na notebooku, který má rozlišení 1024x768 pixelů se při zobrazení textů dosahuje faktického rozlišení 3072x768 pixelů a to je, narozdíl od klasického vyhlazování, dost znát.
  • 21. 7. 2005 12:18

    Petr Cernoch (neregistrovaný)
    Takze si to skutecne shrnme :-) (nedalo mi to) zdroj je:
    # ----------------------------
    # funkce pro vykresleni hlavniho okna
    proc fncHlavniOkno {} {
    	global PRVNI DRUHY TRETI CTVRTY PATY
    	
    	set PRVNI 1
    	set DRUHY 1
    	set TRETI 1
    	set CTVRTY 0
    	set PATY 0
    
    	# vytvoreni komponent okna	
    	frame .c
    	checkbutton .c.prvni -text "Prvni" -variable PRVNI \
                -onvalue 1 -offvalue 0
    	checkbutton .c.druhy -text "Druhy" -variable DRUHY \
                -onvalue 1 -offvalue 0
    	checkbutton .c.treti -text "Treti" -variable TRETI \
                -onvalue 1 -offvalue 0
    	checkbutton .c.ctvrty -text "Ctvrty" -variable CTVRTY \
                -onvalue 1 -offvalue 0
    	checkbutton .c.paty -text "Paty" -variable PATY \
                -onvalue 1 -offvalue 0
    
    	button .stav -text "Vytiskni stav" -width 15 -command {fncStav}
    
            # usporadani komponent okna
    	grid .c -row 0 -column 0 -sticky "W"
    	grid .c.prvni -row 0 -column 0 -sticky "W"
    	grid .c.druhy -row 1 -column 0 -sticky "W" 
    	grid .c.treti -row 2 -column 0 -sticky "W" 
    	grid .c.ctvrty -row 3 -column 0 -sticky "W" 
    	grid .c.paty -row 4 -column 0 -sticky "W" 		
    	grid .stav -row 1 -column 0 -sticky "W"
    }
    
    
    # zjisteni a vytisteni stavu checkboxu
    proc fncStav {} {
    
    	set ls  [winfo children .c]
    	set out [open "file.log" a]
    
    	foreach ctrl $ls {
    		set outln "[$ctrl cget -text] : "
    		set var [$ctrl cget -variable]
    		global $var
    		if {[expr $$var]} {
                        append outln "vybran"
                    } else {
                        append outln "nevybran"
                    }
    		puts $out $outln
    	}
    
    	close $out
    }
    
    
    fncHlavniOkno
    
    # ----------------------------
    
    Kdyz jej date do souboru a nastavite spustitelne atributy, bude to fungovat. Protoze momentalne nejsem na linuxu ale na win, vyresil jsem vystup do logovaciho souboru (viz. fncStav), po jeji zmene na:
    proc fncStav {} {
    
    	set ls  [winfo children .c]
    
    	foreach ctrl $ls {
    		set outln "[$ctrl cget -text] : "
    		set var [$ctrl cget -variable]
    		global $var
    		if {[expr $$var]} {
                        append outln "vybran"
                    } else {
                        append outln "nevybran"
                    }
    		puts $outln
    	}
    }
    
    
    by to melo psat do shellu - momentalne nemuzu slouzit s otestovanim :-)
    Takze to bylo "add 1".

    Add 2 : lepsi je pouzit nejakou tu globalni promennou nez delat v programu psi kusy, to se pise i v ucenych knihach, znalci potvrdi.

    Add 3 : to je snad vyresene

    Add 4 : momentalne by se neco ve smyslu "getState" hodilo, nicmene jedna se o jinak navrzeny jazyk takze je to potreba brat v uvahu

    Dale je vhodne se podivat na

    http://pcernoch.wz.cz/test/

    jsou tam screenshoty ("level 1" i "level 2") vcetne zdrojaku a je tedy mozne to porovnat s vasim produktem.

    Add 5 : vidite v tom nejaky vyrazny rozdil? Dovolil jsem si pouzit ikonky z vaseho programu, nechtelo se mi schanet neco jineho. Co se pouziteho jazyku tyce - vsechno zalezi na kodovani retezcu v programu. Rekl bych ze toto je nutne rucne osetrit v kazdem toolkitu. Definovat klavesove a jine zkratky neni v Tcl/Tk zadny problem.

    Add 6 : nejak se mi to s tou tezkopadnosti nezda - nadefinuji si komponenty, usporadam je do okinka, (jednoduse) definuji udalosti, spustim skript a uz ficim.

    :-)
  • 21. 7. 2005 14:24

    Pavel Tišnovský
    Díky za podporu :-)

    Já jsem ten program napsal schválně tak malý, aby se zase nepředhazovalo, že je tvorba GUI v Tcl/Tk složitá. Ten můj příklad možná vypadá hůř proto, že jsou komponenty defaultně vystředěné (při použití funkce pack). To je však diskutabilní věc, zda má nějaký toolkit defaultně nastavené vystřeďování či zarovnání doleva.

    A díky taky za screenshoty, z práce nemám možnost lézt na Internet jinak než přes port 80, takže je sám nemůžu vystavit.
  • 22. 7. 2005 16:24

    Petr Mach (neregistrovaný)
    Na tohle budu reagovat později, zatím prosím level dva o dopolnění "podtržítek" pro horké klávesy u položek a checkboxů a ukázku zdrojového kódu.
  • 20. 7. 2005 15:13

    Pavel Tišnovský
    Pravda je, že přednosti a zápory 2D syntaxe bych mohl posoudit až po vytvoření většího projektu v Pythonu, což jsem zatím, kromě nastudování knížky o tomto tématu, neudělal. Netvrdím, že Python je špatný, je prostě trošku jiný než Tcl, to je celé (ale ve skutečnosti mají tyto jazyky mnoho společného, narozdíl od statických kompilovaných jazyků)

    Mě u většiny toolkitů (včetně WinAPI a stařičkého Motifu) vždycky vadil ten rozdíl mezi kódem a daty. Buď se část nějakého GUI naklikala a vytvořil se resource, nebo se GUI vytvářelo programově (takto se násilně oddělují dvě společné části, i když ta dělicí čára má být ještě o něco dál - až u callback funkcí). Já nevím, ale mě přijde ta jednotnost program=data velmi mocná, což ostatně částečně odpovídá i na Tvůj poslední dotaz ohledně substitucí a složitých konstrukcí.

    Mě například přijde jako složitá konstrukce vícenásobná dědičnost a naopak jsou lidé, kteří si ji pořád pochvalují. To stejné je s lambda výrazy (jestli to mohu takto napsat): někdo je jimi už od dob Lispu nadšený, někdo je považuje za zbytečně složité (i když na nich ve skutečnosti mnoho složitosti není, ve skutečnosti se opravdu jedná o substituce).
  • 20. 7. 2005 19:05

    cxl (neregistrovaný)
    > Mě u většiny toolkitů (včetně WinAPI a stařičkého Motifu) vždycky vadil ten rozdíl mezi kódem a daty.

    Zkuste U++ (C++ platforma)

    http://upp.sf.net

    Tam se GUI vytvoří visuálně, ale v kódu se to projeví jako C++ templaty, ktere přímo predstavují dialog (nebo jeho část, cokoliv s rozmístěním uživatelských prvků). Jednotnost program/data je pak totální... (a život programátora jednoduchý).
  • 21. 7. 2005 11:07

    Pavel Tišnovský
    Díky za info, vypadá to dost zajímavě (hlavně to porovnání s Qt, wxWidgets a Swingem). Trošku škoda, že to neporovnali se skripty v Tcl/Tk a PyGTK, ale je pravda, že toto je jiná kategorie aplikací.
  • 21. 7. 2005 21:23

    cxl (neregistrovaný)
    No, ono je tezke hledat hezke priklady na srovnani... Nicmene, pokud by se mel implementovat zde uvedeny priklad, mohlo by to vypadat napriklad takhle:

    void Dlg::PrintStatus()
    {
    String txt;
    for(int i = 0; i < checks.GetCount(); i++)
    txt << "Option č. " << i << " je " << (checks[i] ? "zapnuty" : "vypnuty") << '&';
    PromptOK(txt);
    }

    ale neni to zrovna moc typicky ani dobry priklad...

    Tucneho velkeho textu v labelu lze dosahnout (to se zde take resilo :):

    check.SetLabel("\1[*8 Toto je tucny velky text] a tenhle je zase normalni");
  • 25. 7. 2005 10:13

    cxl (neregistrovaný)
    Mno, obe verze jsou skoro na chlup stejne dlouhe. To neni az tak spatny vysledek pro reseni zalozene na C++, ne? A to je jen pidiaplikace...

    Mohu vasi verzi zverejnit tamtez?
  • 25. 7. 2005 13:41

    cxl (neregistrovaný)
    Myslim ze ta verze Pythonu ma drobnou chybu - pri prepnuti jednotky se nezobrazi prepocitany udaj v druhem panelu...
  • 25. 7. 2005 15:33

    Petr Mach (neregistrovaný)
    To je pravda, tohle jsem neimplementoval, údaje se přepočítávají jen při změně hodnoty, ošetření této události je jednoduché. Upravím to.
  • 19. 7. 2005 13:34

    Pavel Tišnovský
    Ještě se zmíním o "kvalitách" toho kterého toolkitu.

    Z GTK znám jeho první verzi (číselně 1.x), ale myslím si, že ani ve druhé verzi nejsou k dispozici následující věci, které Tcl/Tk obsahuje už hodně dlouho:

    1. textový widget, který je editovatelný s podporou hypertextových odkazů, obrázků a formátování textu (velikost textu, barva, atd.)

    2. na Canvas lze přidávat různé tvary (úsečky, kruhy atd.), které se stále chovají jako objekty, takže s nimi lze jednoduše manipulovat, například je posouvat nebo najít objekt, který je nejbližší kurzoru myši.

    I tyto dvě vlastnosti přispívají k tomu, že je Tcl/Tk stále dost často používáno.
  • 19. 7. 2005 14:20

    earl365 (neregistrovaný)
    1. Textovy editor s podporov hypertextov, obrazkov, formatovania Gtk+ ma uz od verzie 2.0, aj ked v prvych verziach nebol prave najstabilnejsi :)

    2. Canvas je sucastou kniznice gnome canvas, funguje podobne ako ten z Tcl/Tk, aj ked zrejme nie je taky jednoduchy.
  • 19. 7. 2005 19:45

    earl365 (neregistrovaný)
    Hmm. Gnome canvas je sice sucast gnome a nie Gtk+, ale myslim, ze od gnome 2.0 je v relativne samostatnej kniznici a bez navaznosti na zvysok gnome. Ale mozem sa mylit, momentalne som trochu mimo, posledny program ktory som pisal s gnome canvas bol este pre gnome 1.4. Vtedy bol gnome canvas napevno v libgnomeui.
    Inak prave Gtk+, hlavne ked sa pouziva v cecku je dost zdlhava kniznica, niektore veci si tam vyzaduju pomerne dost kodu (zvlast napr. ListView s viacerymi stlpcami). Long live glade :)
  • 19. 7. 2005 9:38

    bez přezdívky
    Muj nazor na TK:

    Tk nejni spatny a na male veci je dostacujici. Par veci mi v nem sice take vadi, ale na drobne utilitky je jako stvoreny. Dalsi velkou vyhodou je prave jeho pritomnost v zakladni instalaci pythonu, uzivatel si tak nemusi jiz nic jineho instalovat navic.
  • 19. 7. 2005 9:52

    Hark (neregistrovaný)
    Urcite by bylo fajn napsat i neco o expectu, coz je bezvadna nadstavba nad tcl - a krom knizky Exploring Expect snad o nem neexistuje zadna rozumna dokumentace - nikde.
  • 19. 7. 2005 10:17

    Petr Cernoch (neregistrovaný)
    Diky za hezky clanek, je videt ze jste si na nem dal zalezet.

    Tcl/Tk mam docela rad, stale jej pozivam a nejak se nestotoznuji s vyseuvedenym nazorem o jeho zastaralosti. Proste kazdy existujici jazyk je vhodny k necemu jinemu a Tcl je pro mensi a (treba v mem pripade) multiplatformni projekty stale hodne pouzitelny. Je jednoduchy, prijemny a navic je jeho soucasti snadno pouzitelne rozhrani pro vytvareni GUI.

    Co se vzhledu techto aplikaci tyce, nejak se mi nezda ze by uzivatelovo esteticke citeni bylo nejak ohrozeno. Jestli teda nekdo touzi po polopruhlednych oknech s ruzne tvarovanyma okrajema tak je asi na spatne adrese, to je pravda. Ale kdyz chcete rychle vytvorit funkcni aplikaci se standardnim vzhledem (tlacitka, seznamy, textova pole, prepinace, ramy, popisky), pripadne udelat graficke rozhrani k nejakemu jinemu programu, je to dobra volba.

    Takze shrnuto - i pro zacatecniky bych tento jazyk doporucil protoze je jednoduchy, prehledny, "umi okinka", je multiplatformni a k uprave existujiciho kodu postaci textovy editor ponevadz neni potreba zadna kompilace.
  • 19. 7. 2005 14:26

    LS_999 (neregistrovaný)
    ze vetsi humus nez Tcl/Tk jsem snad jeste nevidel. Tak hnusne widgety
    nema zadny IMHO toolkit. Mozna, ze pro programatory muze byt Tvl/Tk super
    vec, ale pro nas uzivatele je to hnus. To je neco jako mit trabanta
    a vykladat, ze pod kapotou je super motor. I kdyby byl, tak co... ja
    chcu mercedesa se super motorem....
  • 19. 7. 2005 15:08

    Petr Cernoch (neregistrovaný)
    Tak to se bohuzel musim zasmat. Mluvil jste nekdy s nejakym trabantistou?
    Ja ano a zadny si svuj dvoutakt nemohl vynachvalit. A zrovna to porovnani s medakem - na horsim terenu (v horach na snehu) casto vitezil prave ten trabant... podivuhodne ale je to tak.

    Aby odpoved nebyla uplne mimo - proc vsichni kritizuji tvar widgetu?
    V linuxu se mi aplikace tvari jako vsechno ostatni kolem, ve windows totez...
    Hold, asi mam nejakou dokonalejsi verzi protoze podle ocniho vysetreni jsem OK :-)
  • 20. 7. 2005 22:52

    LS_999 (neregistrovaný)
    V trabantu jsem najel nekolik tisic km, takze vim o co jde. No a co se tyka vzhledu a jednotnosti widgetu, pro me
    je to proste dulezita vec. Ja mam rad, kdyz je napr. kniha vysazena hezkym stylem, podle
    nejakych typografickych pravidel, s hezkyma ilustracema.
    Kdyz je vysazena prasacky, tak muze byt sebelepsi autor, ale cte se proste hur.
    Stejne tak se uzivateli pracuje hur, kdyz jsou widgety hnusne, popripade ma kazdy program jine
    widgety....coz je pripad linuxu:(
  • 21. 7. 2005 14:43

    Pavel Tišnovský
    Ano a to je právě ten problém, na který naráží Petr Mach. Tk je uděláno tak, že jako základ využívá na Linuxu "škaredé" widgety (nezapomínejme, že se začínalo na Motifu). Na jiných systémech s tím problém kupodivu není, tam jsou tyto věci do dost velké hloubky standardizovány. Pokud se na Linuxu konečně prosadí rozumný widget set, bude ho Tk určitě používat (protože si to vyžádají uživatelé) a bude po problémech a vcelku nesmyslných flamech.

    S typografií s Vámi naprosto souhlasím, bohužel současně vydávané knížky jsou většinou typograficky mnohem zprasenější, než knížky staré několik desítek let. Zajímavé je, že některá nakladatelství dokážou zprasit i výstup z TeXu, to fakt nepochopím.
  • 19. 7. 2005 17:27

    bez přezdívky
    Nechapu jakou souvislost ma "krasa widgetu" s funkcnosti aplikace. Pokud je program uzivateli uzitecny jiste mu nevadi jiny okraj okna nebo sirsi border tlacitek.

    Krasa je vec relativni a pomijiva, nakonec ocenite spis ten motor, ktery vas doveze do cile...
  • 23. 7. 2005 10:49

    Petr Mach (neregistrovaný)
    To je jednoduche, lidi maji radi krasne veci a davaji jim prednost. Krom toho to ma tak vliv treba na prehlednost UI.
  • 19. 7. 2005 18:39

    Pavel Tišnovský
    Dobrá, donutil jste mě v práci nabootovat XPčka - Tcl widgety i celé aplikace se tam zobrazí přesně podle nastaveného stylu, dokonce to umí i všechny obvyklé klávesové zkratky a antialias fontů! Oproti tomu například Swing si o tomto může nechat jen zdát (dokonce v defaultním stylu nezvládá ani Ctrl+Insert a Shift+Insert). Takže se nejedná o vlastní vykreslování widgetů, používá se systémové, což je IMHO dobře, neboť se tak využijí všechny featurky daného systému.

    A Linux - no to je těžký, když jsme se ještě nedohodli na jedné standardizované a pěkné množině widgetů, co si potom má takový multiplatformní prostředek, jakým Tcl/Tk bezesporu je, vybrat?

    Teď mě napadá, jestli jste neviděl aplikaci tvořenou pomocí sady IWidgets, ty jsou opravdu podivné.
  • 23. 7. 2005 10:45

    Petr Mach (neregistrovaný)
    Linux je svobodny system a kolektivni dilo, v nem nikdo direktivne jednu konkretni GUI knihovnu nepredepise. Ze strany TK je to jen vymluva. Muze si vybrat toolkit jaky chce, nejcasteji pouzivane jsou GTK a Qt. On si vybral zustat osklivy a proto je na linuxu osklivy a neoblibeny.
  • 23. 7. 2005 16:26

    beranek (neregistrovaný)
    Hmm,s C/Tcl/SQL/... pracuju tak 10 let. S Tk nedelam skoro vubec,
    ale existoval jako widget toolkit na unixech, pozdeji na win/mac
    v dobach, kdy zadny linux prakticky neexistoval, natoz GTK, Qt.
    V Tcl/Tk je GUI pro BitKeeper, McVoy na predposledni Tcl konferenci
    hudral na vzhled => Tk se revitalizuje, u Tcl 8.5 je/bude Tile Tk,
    lepsi? s tematy.

    Pro mac je snad ted defaultni TkAqua.
    gnocl je Tcl binding pro GTK, binding pro Qt je snad komercni, pro wx nevim.

    Zajimavy widget je mozna TkZinc, TkTreeCtrl -- ale jen o nich vim

    Ja su s C/Tcl spokojeny, docela mne potesila/prekvapila delka diskuse
    i kdyz je to mozna flame o GUI?

    ad OO: [Incr Tcl], stoop, XOTcl, snit

    zajimave veci jsou urcite jeste: kanaly, VFS, event loop ...
  • 20. 7. 2005 22:38

    LS_999 (neregistrovaný)
    No asi mate pravdu, neni to problem Tcl/Tk, ale linuxu obecne, co program, to jine widgety....bohuzel...
    .
  • 19. 7. 2005 16:12

    JaR (neregistrovaný)
    K tem dvema pristupum k TCL bych mel jeste jeden (ci spise pristup 1,5) - neni treba psat extra program a ten pak volat. Prakticky stejne jednoduche je napsat si treba v C rozsirujici knihovnu a shrnout funkce, ktere zabiraji prilis mnoho casu, prave do ni. Pak definovane funkce volam jako bezne prikazy TCL. Nejlepsi je, ze rozsireni TCL timto zpusobem je skutecne jak pro cvicenou opici a osobne jsem zpusob rozsireni TCL o dalsi knihovnu v C pochopil a ve svem skriptu realizoval drive, nez jsem vubec byl schopen v C neco napsat sam.
    A co se nevyhod tyka - ano, jsou, casto byva peklo s vhodnou kombinaci {}", ale pro mne treba BLT a expect proste nemaji zadne stejne snadno pouzitelne ekvivalenty v jakemkoli jazyce na ktery jsem dosud narazil.
  • 19. 7. 2005 17:49

    petr_p (neregistrovaný)
    Vyborny clanek a doufam ze i serial. Jen bych mel prosbu na typografa/korektora Roota, aby na bezne zvyrazneni pouzival em a ne strong. Myslim, ze zas tolik silnych (strong) myslenek text neobsahoval. Dale pokud sklonujete zvyrazneny termin, zvyraznete jej cely vcetne vsech pripon a koncovek.
  • 19. 7. 2005 18:30

    Pavel Tišnovský
    Já jsem ve svých předchozích článcích samozřejmě používal "em" (stejně jako v LaTeXu, kde jsem \textbf použil snad jednou za sto stran), ale někde mezi mým XHTML souborem s článkem a výsledkem na Rootu se všechny em-ka prostě ztratí. Asi to vyfiltruje redakční systém, nevím. Proto používám "strong", i když to typograficky vypadá strašně (ještě se přiznám, že nepoužívám nedělitelné mezery, ty by se taky hodily).
  • 19. 7. 2005 18:21

    bez přezdívky
    Jsem rád, že začne vycházet seriál o Tcl/Tk. Sám jsem se tento jazyk učil v dobách, kdy výše zmiňované alternativy nebyly nebo byly v plenkách. Rozhodně má tento jazyk díky své jednoduchosti co nabídnout. Jistě má své mouchy asi jako každý jazyk, ale pokud mohu srovnávat s ostatními tak je opravdu velice jednoduchý a dá se použít téměř na cokoliv, nehledě na snadné propojení s C. Kdysi jsem viděl i OpenGL rozšíření, ale to už jsou takové speciality. Spolu s Tk se hodí na protypování user interface nebo pro rychlé vytvoření GUI nějaké konzolové aplikace resp. jako frontend přepínáčů. Má však i své stinné stránky a to především pokud je aplikace (v C) využívající Tcl/Tk vícevláknová to může přinést nějaký ten problém při překreslování.
    Určitě také stojí za zmínku, že canvas podporuje export do postscriptu a dá se docela dobře použít pro grafický výstup z nějakého skriptu.

    Pro uživatele Tck/Tk může být užitečná příručka tkref, která přehledným způsobem popisuje základní příkazy (http://www.slac.stanford.edu/~raines/tkref.html).
    Přeji hodně zdaru v dalších dílech.
  • 23. 7. 2005 15:55

    stefan (neregistrovaný)
    Mna by zaujimalo, ako by vyzeral vyssie uvedeny priklad s checkboxzmi pri pouziti Python + tkinter. Ma niekto riesenie? Ja to skusim s pouzitim wxPython. Celkom sa mi to hodi, lebo wxWidgets poznam len z c++ takze sa pozriem na to, ako sa veci maju v Pythone.
  • 24. 7. 2005 9:37

    Petr Mach (neregistrovaný)
    Tady je upravene reseni pro TK a GTK v jednom pythonim zdrojaku.
    #!/bin/env python
    # -*- coding: utf-8 -*-
    
    checkNames = ['První', 'Druhý', 'Třetí', 'Čtvrtý', 'Pátý']
    
    # TK VARIANTA ############################################################
                                                                             #
    import Tkinter as tk                                                     #
                                                                             #
    # obsluha udalostí ------------------------------------------------------#
                                                                             #
    checks = []                                                              #
    def printStatus():                                                       #
        global checks                                                        #
        for name, status in checks:                                          #
            if  status.get():                                                #
                print name, "je zatžen."                                     #
            else:                                                            #
                print name, "není zatržen."                                  #
                                                                             #
    # vytvoření GUI ---------------------------------------------------------#
                                                                             #
    root = tk.Tk()                                                           #
                                                                             #
    frame = tk.Frame(root)                                                   #
    frame.pack()                                                             #
                                                                             #
    for name in checkNames:                                                  #
        var = tk.IntVar()                                                    #
        checks.append([name, var])                                           #
        widget = tk.Checkbutton(frame, text=name, variable=var)              #
        widget.pack()                                                        #
                                                                             #
    pButton = tk.Button(frame, text="Tiskni výsledky", command=printStatus)  #
    pButton.pack()                                                           #
                                                                             #
    # čekání na událost -----------------------------------------------------#
                                                                             #
    root.mainloop()                                                          #
                                                                             #
    #######################################################################
    
    # GTK VARIANTA ###########################################################
                                                                             #
    import gtk                                                               #
                                                                             #
    # obsluha udalostí ------------------------------------------------------#
                                                                             #
    def printStatus(button, checks):                                         #
        for check in checks:                                                 #
            if  check.get_active():                                          #
                print check.get_label(), "je zatržen."                       #
            else:                                                            #
                print check.get_label(), "není zatržen."                     #
                                                                             #
    # vytvoření GUI ---------------------------------------------------------#
                                                                             #
    vbox = gtk.VBox()                                                        #
                                                                             #
    checks = [ gtk.CheckButton(label=name) for name in checkNames ]          #
    for check in checks:                                                     #
        vbox.pack_start( check )                                             #
                                                                             #
    qButton = gtk.Button( label="Vytiskni stav" )                            #
    qButton.connect( 'clicked', printStatus, checks )                        #
    vbox.pack_start(qButton)                                                 #
                                                                             #
    win = gtk.Window()                                                       #
    win.connect( 'destroy', lambda x: gtk.main_quit() )                      #
    win.add(vbox)                                                            #
    win.show_all()                                                           #
                                                                             #
    # čekání na událost -----------------------------------------------------#
                                                                             #
    gtk.main()                                                               #
                                                                             #
    #######################################################################
    
  • 24. 7. 2005 12:43

    stefan (neregistrovaný)
    Dakujem za bleskovu reakciu. Vyzera to velmi jednoduche, hlavne v porovnani s wxPythonom. Zatial pripajam len link na celkom zaujimave dema vo wxPythone:

    http://www.pythonapocrypha.com/Chapter21/Chapter21.shtml
  • 24. 7. 2005 14:19

    stefan (neregistrovaný)
    testovane v konfiguracii: python-2.4.1, wxPython-2.5.3

    import wx
    
    class ChecksDialog(wx.Dialog):
        
        ID_BUTTON_PRINT = 5001
        
        def __init__(self, parent, ID, title):
            wx.Dialog.__init__(self, parent, ID, title)
    
            sizer = wx.BoxSizer(wx.VERTICAL)
            
            labels = ['first', 'second', 'third', 'fourth', 'fifth']
            
            self.checks = [wx.CheckBox(self, -1, label) for label in labels]
            for check in self.checks:
                sizer.Add(check, 0, wx.ALL, 5)            
                
            button = wx.Button(self, self.ID_BUTTON_PRINT, 'Print')
            sizer.Add(button, 0, wx.ALL|wx.ALIGN_CENTER, 5)
            
            wx.EVT_BUTTON(self, self.ID_BUTTON_PRINT, self.OnButton)
            
            self.SetSizerAndFit(sizer)
                    
        def OnButton(self, event):
            for check in self.checks:
                if check.IsChecked():
                    print check.GetLabel(), ' checked'
                else:
                    print check.GetLabel(), ' not checked'
    
    class ChecksApp(wx.App):
        def OnInit(self):
            dlg = ChecksDialog(None, -1, "Checkboxes Demo")
            dlg.Show(True)
            self.SetTopWindow(dlg)
            return True
    
    app = ChecksApp(0)
    app.MainLoop()
    
    
  • 24. 7. 2005 21:42

    slacker (neregistrovaný)
    Dovolil bych si provést menši opravu. Jinak se aplikace při zavření okna neukonči korektně.
    #!/usr/bin/python
    # -*- coding: iso8859-2
    
    import wx
    
    class ChecksDialog(wx.Dialog):
        
        ID_BUTTON_PRINT = 5001
        
        def __init__(self, parent, ID, title):
            wx.Dialog.__init__(self, parent, ID, title)
    
            sizer = wx.BoxSizer(wx.VERTICAL)
            
            labels = ['first', 'second', 'third', 'fourth', 'fifth']
            
            self.checks = [wx.CheckBox(self, -1, label) for label in labels]
            for check in self.checks:
                sizer.Add(check, 0, wx.ALL, 5)            
                
            button = wx.Button(self, self.ID_BUTTON_PRINT, 'Print')
            sizer.Add(button, 0, wx.ALL|wx.ALIGN_CENTER, 5)
            
            wx.EVT_BUTTON(self, self.ID_BUTTON_PRINT, self.OnButton)
            wx.EVT_CLOSE(self, self.OnQuit)
            self.SetSizerAndFit(sizer)
                    
        def OnButton(self, event):
            for check in self.checks:
                if check.IsChecked():
                    print check.GetLabel(), ' checked'
                else:
                    print check.GetLabel(), ' not checked'
    
        def OnQuit(self, event):
            self.Destroy()
    
    class ChecksApp(wx.App):
        def OnInit(self):
            dlg = ChecksDialog(None, -1, "Checkboxes Demo")
            dlg.Show(True)
            self.SetTopWindow(dlg)
            return True
    
    app = ChecksApp(0)
    app.MainLoop()