Vlákno názorů k článku Vifm: správce souboru á la Vim od Pavel Tišnovský - Malé upřesnění: vi nevznikl na osobních počítačích a...

No, ale vi bude neergonomické prakticky podle jakéhokoli měřítka...

Pro lidi, kteří mají problémy s myší, zřejmě ne.

Windows se dají kompletně ovládat bez myši, a to daleko lépe, než linuxová GUI. Když se naučíte používat klávesu context menu, a zjistíte že stiskem Alt+podtržené-písmeno-z-mnu to menu otevřete, a tabem se přesouváte mezi prvky v dialogu, tak vám toho už moc nechybí. Srovnejte se učením vi.

Editor vi porušuje zásady tvorby UI, a nic na tom nemůže změnit fakt, že byl nejspíš napsán před vznikem těchto zásad. Samozřejmě kdo je masochista, dobře mu tak. Když jsme u toho, jaký konfigurační balík Vimu splňuje požadavky?

Připomínky k SLES lze jistě zanášet do bugzilly, ale to bych nedělal celé dny nic jiného. Stejně Novell ani nikdo jiný ve světě open source nemá dost prostředků, aby bylo GUI slušně udělané. Celkově neergonomický se týká třeba členění dialogů a plýtvání místem v nich.

Když říkáte, že stačí problém lépe popsat, zkusím to. Po startu SLES 10 SP1 dostanu hlášku, že X11 server nenastartoval. Nabídne mi to logy, ve kterých xserver hledá S3 Trio 64, nenajde ho, a umře. Když se poté přihlásím v textu, a napíšu xstart, xserver najede bez problémů. V YaSTu (který na to spouští sax2) je jako zařízení vybráno SVGA, a předpokládám, že po bootu xserver používá stejný konfigurák, jako při puštění startx (resp nevidím důvod, proč by to mělo být jinak).
Jak jsem psal, jistě se v tom dá hrabat, a problém nějak vyřešit. Ale dávám přednost tomu, když věci prostě fungují.

mate pravdu. GUI v Linuxu je nedodelek. Bohuzel to tak ale *navzdy* zustane protoze dodelat to GUI poradne by stalo nekolik let prace a vynalozene financni prostredky by se nevratili ponevadz vase konkurence muze diky GPL vyuzit vysledky vasi prace zcela zdarma. Kdo by to tedy delal?

Ja taky davam prednost vecem ktere funguji, ponevadz se pocitac pouziva jako pracovni nastroj a nikoliv samoucelne. V linuxu musite resit spoustu veci, ktere ve windows proste funguji, stoji to cas, ktery vam pak chybi ponevadz se misto svemu byznisu venujete nefukcnimu pocitaci.

Stejne je to s kancelarskymi baliky. Spravna otazka je, proc ma linux (nebo open office) jen 1% zastoupeni prestoze je zadarmo. Protoze zadarmo neznamena nejlevneji.

Víte, vy tu stále argumentujete BFU. Ale já i přes veškerou skromnost nejsem BFU a se mnou tisíce jiných. Co vyhovuje BFU nemusí nutně vyhovovat zkušenějším či vyhraněnějším lidem. A UI je přesně jednou z těchto věcí. Pro mne je jednodušší a přirozenější zadávat počítači příkazy, jež mají nějakou logiku a dají se skládat v složitější celky, podobně, jako se dají skládat elementy lidského jazyka. Taková forma komunikace mi připadá mnohem přirozenější, nežli nějaké klikání po obrazovce s myší, kdy si práci můžu ulehčit maximálně tím, že si mohu zapamatovat pro ty nejelementárnější příkazy jakési, často nelogické, klávesové zkratky, nebo si jich pár vytvořit."

Na tohle téma mě napadá jeden moc pěkný citát... "A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures." Jakékoli grafické ovládání stylem [podstatné_jméno] sloveso (což je asi tak maximum, co klasické windowsoidní GUI umi, i po započtení klávesových zkratek) bude žalostně neúplné proti složitosti úkonů, které ve skutečnosti chce člověk dělat. Pro příklady určitě není třeba chodit daleko. :]

Jenže GUI v 70. letech vznikalo především ve snaze přiblížit počítače obyčejným lidem a dětem. Cílem nemělo být vyhlášení GUI za jediné správné dogma. Závislost pracnosti ovládání na obtížnosti řešeného problému je u GUI inverzní funkcí k "CLI" (nebrat úplně doslova, proto ty uvozovky) - u CLI příznačné "těžko na cvičišti, lehko na bojišti", u GUI přesně naopak.

Já jsem zastáncem používání GUI na místech, kde to má své opodstatnění. Navíc nejhorší, co se může stát, je podřizovat funkčnost programu jeho ovládání. A to je přesně model, který s sebou použití GUI obvykle přináší z hlediska programátora. Tahle věc se snad poprvé objevila u TurboVision či VisualBasicu a od těch dob zbytostněla tak, že ji už mnozí považují za normální a přirozenou.

Nechci vypadat jako člověk, který paušálně odmítá GUI jako takové. Nicméně, když si vybavím některé formuláře GUI, často se mi vybaví ono lidové "dej blbci funkci a vymyslí lejstro". Já opravdu po počítači nechci, aby simuloval komunikaci mezi mnou a jím pomocí lejster či aby svým vzhledem napodoboval ovládací panely různých zařízení typu hifi věž, kancelářský stůl (se svým nepořádkem) apod. Já naopak chci využít tu obrovskou možnost, že počítač se mnou dokáže komunikovat na úrovni, jež je o několik řádů blíže psanému slovu lidského jazyka, nežli lejstro na úřadě. Jazyk se taky nejdříve musíte naučit a není to zrovna zpočátku nic intuitivního, ale získáte mnohem víc, než kdybyste se po zbytek života omezili na komunikaci pomocí kreslení obrázků. Přesně, jak praví ten váš citát...

Já přeci taky GUI paušálně neodmítám. :-) Váš přístup mi přijde velmi rozumný, cítím to hodně podobně.

Od sedmdesátých let se také výrazně změnila skupina lidí, která počítač používá. Dnes nikdo nechce dělat IT, stejně jako nikdo nechce dělat mzdy nebo účetnictví. IT je věc, která firmy stojí peníze, a generuje náklady. Účelem je, aby IT poskytlo co nejvíce služeb za co nejméně peněz. Náklady na lidské zdroje jsou toho důležitou částí. Proč mít liftboye (takový ten hoch ve výtahu, co ho obsluhuje, jestli si pamatujete), který stráví půl roku tím, že se učí editovat textové soubory? Navíc ve chvíli, kdy vlastní editace souborů není primární pracovn náplní daného člověka?

Já jsem necitoval, ale mohu říci tolik, že command line interface, natož třeba Perl, není přirozené komunikaci nijak blízko. Může vám to tak připadat poté, co se naučíte zpaměti stovky příkazů vi, další stovky příkazů shellu (plus jejich syntaxi), tisíce zkratkových kláves, umístění stovek konfiguráků, a až to celé budete pár let používat. Potom to ovšem není tak, že by s vámi počítač komunikoval na úrovni mluveného slova, ale tak, že vy komunikujete s počítačem na jeho úrovni. Na rozdíl ode mne si zřejmě nemyslíte, že jsou to stroje, kdo má pomáhat v práci lidem, a m se jim pizpůsobovat, a vidíte to zcela opačně.
Otázkou je, proč výše uvedené memorování absolvovat, když totéž zvládnete jen se znalostí *principů* (co, nikoliv jak), a se základní znalostí nástrojů.

...command line interface, natož třeba Perl, není přirozené komunikaci nijak blízko.

To je zajímavé, Perl navrhl profesionální lingvista, a jako programovací jazyk založený na přirozeném způsobu komunikace ho navrhl zcela úmyslně. Zajímavé, že i Microsoft něco z toho převzal. :-)

Zato Vám přijde jako přirozenější způsob komunikace myš a ikonky. Mně tedy ne, já si svého času přestal hrát s omalovánkami v pěti letech a v sedmi jsem začal programovat. Nikoli ovšem myší. Jiní lidé třeba neprogramují, ale mluví česky, nikoli piktografickými posunky.

One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful.

“The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.”

Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand.

“I don't understand you!” said the programmer.

Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window.

“What are you trying to tell me?” asked the programmer.

Master Foo pointed at the programmer's head. Then he pointed at a rock.

“Why can't you make yourself clear?” demanded the programmer.

Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan.

As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him.

At that moment, the programmer achieved enlightenment.

:-)))

Zkuste předložit zdroják v Javě, C# a Perlu člověku, který nemá zkušenosti s počítači, a zeptejte se ho, který z nich mu přijde blíže lidské řeči. Perl to nebude :)

V sedmi letech jsem také začínal. A někdy okolo 17 let věku jsem zjistil, že jednoduché věci je lepší dělat jednoduše. Na vás to nepřišlo?

> To je zajímavé, Perl navrhl profesionální lingvista, a jako programovací jazyk založený na přirozeném způsobu komunikace ho navrhl zcela úmyslně.

A lide by si z toho meli vzit ponauceni a profesionalni lingvisty priste radsi k navrhu formalnich jazyku nepoustet :-) .

V tom případě je dobře, že Perl je velmi neformální jazyk. :-) (Ty jsi Bash-only? ;-))

> Ty jsi Bash-only?

Unixovy shell povazuju za druhy vyznamny a pametihodny odstrasujici priklad z historie programovacich jazyku.

Ne ze bych ho tedy nepouzival, ale tak na veci do deseti radku. Zpracovani textu delam vetsinou v AWKu, komplikovanejsi veci ve Scheme (SCSH nebo Guile).

Takže používáš Emacs? ;-) Teda Guile nemusím, to už radši Gauche. :-] Ale Scsh beru, to je sympatická věc.

Pouzivam.

Tak to jo, já dosud myslel, že jsi vimař. :-)

Já mám stále pocit, že mi nechcete rozumět. Já netvrdím, že se nezměnila skupina uživatelů. Co tvrdím, je to, že stále existuje významná skupina uživatelů, pro něž počítač není nepochopitelný stroj, který je nezbytné vybavit takovým ovládáním, že to pochopí i člověk s IQ 50. Tak mi necpěte do mého počítače to vaše ovládání šité na míru průměrnému uživateli, který počítač ovládá na zcela jiné úrovni, nežli já, a ani si na víc nedělá ambice. Pro mě je takovýto způsob práce s počítačem vysoce neefektivní a nepohodlný a na druhou stranu mi nedělá nejmenších potíží zvládnout pár desítek příkazů a pochopit jednoduchou gramatiku, jež je svazuje dohromady a vytváří z nich komunikační a ovládácí nástroj o několik řádů silnější a robustnější, než vaše GUI vymyšlené na míru technickým antitalentům.

Takže - pokud editace textů pro někoho není důležitou součástí pracovní náplně, tak ať nepoužívá textový editor šitý na míru účelům profesionální a efektivní editace textů. Nikdo ho k tomu nenutí.

Pro VÁS třeba není příkazový řádek přirozený. Pro MNE ano. To, že něco není přirozené pro vás, přece neznamená, že se nenajde někdo jiný, pro něhož to přirozené je.
Pokud jde o vi, tak vás ujišťuji, že žádné stovky příkazů jsem se nikdy učit nemusel. Ty nejzákladnější spočítáte na prstech, další domyslíte z logiky těch základních a zbytek je jen logickou kombinací jednodušších a jejich parametrů v komplexní celky. Vyhledání nějakých specialit v dokumentaci v tomto případě není o nic složitější, než vyhledání dané funkcionality kdesi v hloubi hierarchie menu a formulářů GUI orientovaných editorů, kde se to stejně často bez nápovědy neobejde.
Totéž u shellu - nedal bych tu z hlavy snad ani padesátku příkazů.
Tisíce klávesových zkratek si opravdu, ale opravdu v CLI nebo vi pamatovat nemusíte. Ono jich tam dohromady víc jak 5 sotva bude, dá-li se tomu vůbec říkat klávesové zkratky. Tato prostředí žádné klávesové zkratky totiž ke svému ovládání nepotřebují.
Stovky konfiguráků? Tak třeba v Linuxu ty stovky konfiguráků jsou obvykle umístěny s trochou nadsázky na jednom místě. Je pro mne mnohem jednodušší na tom místě konfigurák najít a zeditovat, než se proklikávat kdesi formuláři a menu, než narazím na to, co potřebuji, a než mi GUI postupně, pomalu poodhalí, co vlastně všechno můžu měnit. Obvykle to právě v GUI bývá rozhozeno na více místech a nezřídka tam, kde by to člověk nejméně čekal. V konfiguráku je vše na jednom místě a pohodlně to v něm najdu. V GUI se to často podobá bloudění bludištěm.
Pokud jde o to, kdo má komu pomáhat, tak jsem přesvědčen, že sednul-li byste si vedle zkušeného uživatele vi a měl se s ním poměřit v rychlosti editace (vy samozřejmě ve vašem oblíbeném GUI editoru), tak to pro vás skončí fiaskem. U mne byl pohled na práci takového člověka důvodem, proč jsem přestal vi(m) nenávidět a začal ho obdivovat. Takže by se jasně ukázalo, že to, co preferuji já, uživateli nakonec pomáhá mnohem více, než vámi preferované přístupy. Jen narozdíl od těch vašich vyžadují určitou počáteční mentální a časovou investici, která se ovšem mnohonásobně vyplatí.

Takže odpověď na vaši poslední větu je jednoduchá - protože se mýlíte. Není tomu tak. Oba přístupy mají své silné a své slabé stránky. Naklikat elektrické schéma je pro mne snažší s pomocí GUI než v nějakém textovém popisu, naproti tomu vytvořit 300 uživatelů na novém serveru na podkladě informací v databázi je pro mne jednodušší s pomocí CLI, nežli se uklikat k smrti (zkušenost s WinNT v polovině 90. let).

Rozdíl mezi oběma přístupy bych charakterizoval asi tak:
- GUI je postaveno na intelektu a předvídavosti jeho autora; uživatelův intelekt a schopnost učit se téměř zcela ignoruje/nevyžaduje; výhodou je prostředí, v němž je extrémně jednoduché na první pohled pochopit, jak dělat jednoduché věci; daň je z mého pohledu nepřijatelně vysoká - razatní omezení extenzibility doprovázené masivním nárůstem komplexity
- CLI naopak spoléhá na tento intelekt a schopnost učit se a dává uživateli do rukou nástroj, jímž může jednotlivé složky systému kombinovat téměř neomezeně do výkonných či datových celků přesně podle uživatelových představ; to vše při zachování jednoduchosti a nenáročnosti

Z toho také plyne, kterým cílovým skupinám bude vyhovovat jaký přístup, nebo - lépe - kterým cílovým skupinám bude který přístup nevyhovovat. Skupina, jíž jsem členem já, nevidí důvod vzdávat se při ovládání počítače své lidské přirozenosti učit se a myslet, ale naopak - tyto schopnosti chce zkombinovat se schopnostmi počítače. CLI mi v tomto ohledu obecně dává mnohem větší prostor, nežli GUI.

Takže si myslíte, že když jednoho uživatele zakládám z GUI, a 300 uživatelů pomocí Excelu, tak je pro mě počítač nepochopitelný stroj? Nebo myslíte, že třeba ovládání MS Office, AutoCadu, Photoshopu, Visual Studia a dalších GUI aplikací je stavěné pro lidi s IQ 50? LOL podruhé.

Zajímalo by mě, jak používáte stovky příkazů, když jste se jich naučil méně než 20 (pokud netrpíte mnohoprstností), a tisíce zkratkových kláves, když jste se jich naučil 5 (ty stovky a tisíce tu někdo uváděl, moje spojení je pomalé, tak to teď nebudu hledat).

Ano, je možné, že po letech deformace unixovými shelly, ovládáním vi, a podobnými příšernostmi, vám připadá logické otevřít konfigurák ve vi a nastavit v něm hodnotu. Mě to připadá jako vyhozený čas, a rozšíření GUI nástrojů (nakonec i na unixech - YaST, SAM, smit a další) mi dává zapravdu.

Jak jsem psal v prvním odstavci, GUI musíte umět používat. Uživatele můžete založit třeba v Excelu, nebo nakonec skriptem stejně jako na unixech (net add user, příkazem for /f tomu nacpete data).

Náš pohled na GUI vs CLI je rozdílný, ale přesto se v něčem shodneme. Já mám za to, že GUI umožňuje dělat jednoduché věci jednoduše. Nevidím důvod, proč by třeba admin měl jednoduché věci dělat složitě jen proto, že je schopen se ty složité věci naučit (viz to ovládání telefonů, o kterém jsem dnes psal). Na druhé straně je pravda, že velmi neobvyklé akce (a mezi ně založení uživatele opravdu nepatří) se GUI dělaj obtížně. Pak je třeba mít buď velmi dobré GUI, nebo použít jiné nástroje. Skriptování, programování i používání command line pak má dobrý smysl. Nakonec já používám i ve Windows command line rád a často. Ovšem jako podpůrný prostředek pro neobvyklé akce, ne pro běžné aktivity.

Ty vaše "výkonné celky" jsou ve skutečnosti triviality, které začínají a končí na command line. Když zkusíte tímhle způsobem provést jakýkoliv task z reálného světa (tedy mimo administraci unixů), tak brzo dojedete. Zaúčtujte faktury z command line, opravte červené oči na fotce (pokud možno lépe, než v tutorialu Gimpu tady na rootu), spočítejte kalkulaci nákladů na zakázku v tabulkovém kalkulátoru a vložte výsledek do dokumentu word processoru, založte emailový účet v KMailu, vyrobte zákazníkovi náhled střihů vlasů podle dodané fotografie (to dělají kadeřníci), zarezervujte si letenku. zjistíte, že v unixech naprosto můžete se skvělou efektivitou... administrovat unixy, což je v podstatě zbytná činnost, které bychom se jako IT obor nejraději zbavili (myslím administrace celkově).

Ano, někdy mi to tak připadá. Ovládání MS Office je z mého pohledu skutečně ENORMNĚ nepohodlné a neefektivní. Přesně, jak tu někdo poznamenal - jednoduché věci dělá ještě jednoduššími, složité ještě složitějšími. Od lidí jakou jsou sekretářky se asi nepředpokládá rozsáhlé využívání všelikých možností, jež MS Office nabízí - jednoduché věci jsou tedy ještě více zjednodušeny. Čím to je, že 90% uživatelů nepoužívá více jak 10% funkcí MS Office? Těch 10% je přesně ta část, která je jednoduchá.
Jinak opravdu nevím, jak byste pomocí Excelu chtěl ve WinNT 3.něco nebo kolikátá to byla verze přidat 300 uživatelů, když jediná možnost přidání uživatele byla pomocí formuláře pro vytvoření jednoho uživatele. Cosi jako unixový /etc/passwd jistě existoval i zde, ale byl binární a jeho formát nezveřejněný.
A pokud jde o AutoCAD, tak jsem speciálně na téma CADu upozornil jako na vhodný případ použití GUI v minulém příspěvku. Jenže pokud jde konkrétně o AutoCAD, tak tam autoři velice správně pochopili, že spoléhat se pouze na GUI je příliš omezující a to, co dělá z AutoCADu skutečně mocný nástroj, je možnost rozšiřovat ho v LISPu. A snad je vám jasné, do které kategorie UI tento prostředek jednoznačně patří.

No a jsme u toho - prostředky GUI by taková věc byla zřejmě tak náročná, že i tvůrce GUI na ni raději rezignoval a ponechal to v CLI. Které ovšem u WinNT v polovině 90. let bylo na takové úrovni, že jeho praktická použitelnost byla v podstatě vyloučena.

Jak vidím, tak v pohledu na GUI se shodujeme víc, než jsem si dříve myslel. Můj názor je, že je vhodné obojí vyváženě kombinovat. I při tom klikání schématu ocením, když na příkazovém řádku můžu napsat "bus A(0..24)" místo toho, abych takovou strukturu musel zdlouhavě naklikávat. Zkrátka GUI na běžné jednoduché věci, CLI na speciality. Jenže současný trend je spíše CLI osekávat a do GUI nacpat úplně všechno, a co je přirozeně nevhodné pro GUI, tak složitě "ochcávat", aby to nějak na to GUI napasovat šlo (typicky veškeré konstrukce, vyžadující turingovskou úplnost prostředku k jejich popisu).

Pro administrátora unixů je administrace unixu "task z reálného světa" :-) A takový administrátor Windows pak může promakané CLI nástroje svých unixovýxh kolegů jen tiše závidět. Tedy nevím, jak je to dnes, ale v dobách, kdy jsem se musel potýkat s NT jsem tyto pocity zažíval často. Pokud jde o ty faktury - pokud jich máte na konci kvartálu účtovat tisíce, tak už stojí za popřemýšlení, jak na to ;-) Zvláště, jsou-li na jedno brdo a je třeba u nich měnit jen nějakou položku a ta položka se vyskytuje třeba v databázi skladníka. Pak výhodu CLI nad GUI vidím naprosto markantní. To samé u těch rezervací letenek - pokud by jich bylo třeba rezervovat spousty (což je práce pro letištní personál celkem obvyklá), pak to taky na celou věc vrhá jiné světlo. Tabulkový procesor bych viděl jako jedinečný příklad zdárného propojení GUI a CLI, kdy jednotlivé objekty GUI jsou vzájemně propojeny objekty CLI (tedy výrazy apod.). Ovšem je třeba si uvědomit, že počítače ulehčují práci především při zpracování mnoha dat. Vystavit jednu fakturu bych mohl klidně i bez počítače, v podstatě pro mne pak počítač nepředstavuje žádný větší přínos (kromě archivace). Tu práci mi počítač výrazně ulehčí v okamžiku, kdy jich je hodně a tam taky naplno vystupují možnosti CLI.

U toho vi záleží, co považujete za příkaz. Zda povel, který napíšu v příkazovém módu, nebo ty elementy, z kterých svůj povel sestavím. Pokud to první, pak má vi příkazů teoreticky nekonečně, pokud to druhé, tak si s těmi dvaceti příkazy bohatě vystačím. Vi žádné klávesové zkratky nemá, vi má příkazový mód, kterým klávesové zkratky nahrazuje. Jediné, co by se dalo nazvat klávesovými zkratkami, jsou povely pro přecházení mezi těmito dvěma základními režimy (typicky klávesa ESC a INS), možná by se dalo přijít ještě na něco, nevím, nikdy jsem nad tím nepřemýšlel. Filosofie ovládání je ve vi diametrálně odlišná od "klasických" textových editorů, včetně myšlení u toho - v klasickém editoru je text nahlížen spíše z grafického pohledu (m. řádek, n. sloupec...), zatímco ve vi je preferován kontext (začátek/konec slova, řádku, odstavce, stránky, jiného sémantického bloku (dvojice závorek stejného typu, uvozovek...) apod.) Je mi jasné, že to je šok pro někoho, kdo je zvyklý na ten přímočarý přístup klasických editorů, já jsem nebyl výjimkou. Po prvním seznámení se s vi v učebnici Unixu jsem přemýšlel nad tím, na čem autor takové zhůvěřilosti jel (jestli to bylo LSD nebo něco ostřejšího). Teprve s odstupem času, když jsem odhodil staré předsudky a hlavně na vlastní oči viděl, jakým způsobem se dá s pomocí vi pracovat s textem, když to někdo umí, jsem se o něj začal více zajímat.

Pro vás je editace konfiguráku vyhozený čas, já takovou editaci provedu za nepoměrně kratší dobu, než průměrný člověk s pomocí GUI. Zvláště když danou věc konfiguruji popáté. Nebo když je třeba konfiguraci nějak zautomatizovat, což GUI v podstatě zcela vylučuje. Důvod uvedení GUI nástrojů do unixového prostředí je dle mého názoru stejný, jako jinde - kvůli zvýšení atraktivity pro uživatele, kteří nejsou ochotni se nic učit. Já souhlasím, že takových je dnes většina a byznys je byznys. Ovšem jestli to stačí jako důvod k odstranění klasického negrafického UI, to bych se hádal. Oni totiž ti BFU těžko nějak zásadně počítače mohou dále rozvíjet a pro experty je omezení se na GUI opravdu omezující. Přirovnal bych to k situaci, kdy většina lidí neumí číst a psát - pro ně je určitě vhodnější použít piktogramy "záchod", "východ", "pitná voda" apod., než je nutit učit se číst a psát jen lvůli tomu, aby si mohli přečíst to, co se dá snadno namalovat. Ale pro samotné autory zařízení takto "popsaných" by asi komunikace v piktogramech nebyla příliš šťastným řešením.

Celkem by mě zajímalo, proč vidíte ovládání MS Office jako extrémně nepohodlné. GUI Office 2007 je designované podle Fitts's law (viz wikipedia), přehledně tříděné do záložek, a dá se velmi efektivně ovládat z klávesnice. Třídění na záložky proběhlo na základě sběru dat, který zkoumal užívání funkcí Office u veliké hromady uživatelů. Usability testy vykazují vynikající výsledky. Jediný problém je v tom, že předchozí verze měly ovládání jiné, a lidé si neradi zvykají na novinky.

Jak jste přišel na to, že se od sekretářek neočekává rozsáhlé využívání všelikých možností MSO? Naopak při pozorování schopné sekretářky uvidíte, že MSO neumíte používat zdaleka tak dobře, jako ona. Totéž zjistíte u Excelu, když uvidíte, co s ním provádí finanční ředitel.

Proč si myslíte, že 90% uživatelů MSO využívá jen 10% funkcionality? Máte k tomu nějaké podklady, nebo je to jen urban legend, nebo to soudíte podle sebe? Ono to bude psíše něco typu 60% uživatelů používá jen 40% funkcí. Problém je v tom, že u každého uživatele jsou to jiné funkce, takže nelze ořezat "zbytečné" funkce".

Pokud jde o AutoCad, tak ten se dá rozšiřovat hlavně ve VBA. VBA je jednodušší, lépe se učí, a je rychlejší. Navíc VBA umí v podstatě každý pokročilý uživatel MS Office, což se o LIPSu říci nedá. Viz třeba zde:
http://www.contractcaddgroup.com/VBA/visible/vsibility.htm
Obdobně samozřejmě můžete rozšiřovat MS Office a family (Publisher, Visio), Corel Draw a další. Z VBA můžete používat COM, i řadu funkcí Win32 API, a tvořit UI, takže si můžete vyhrát
(problém je, že řada lidí si hraje dost příšerně, protože umí programovat, ale neumí zacházet s platformou, pro kterou píší, tedy třeba s MSO). Vyjma toho máte možnost rozšiřovat aplikace pomocí pluginů (COM objekty), nebo je skriptovat z externího kódu (VB, C++, .NET, obdobně jako z VBA). Tyto možnosti bych rozhodně nepopisoval jako CLI interface ;)
Windows nejsou unix, a proto umí přidat uživatele více způsoby. Máme dokumentované API pro přidání lokálního i doménového uživatele, máme command line utilitu, a máme GUI.
V Excelu přidáte těch pár set uživatelů mnoha způsoby. Jakožto příznivce unixů může spustit command line utilitu, můžete použít COM objekty (http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true ; http://techtasks.com/code/viewbookcode/378), nebo zavolat Win32 API (NetUserAdd). Vše je samozřejmě dokumentované. Problém je v tom, že neznáte nástroje, které by měl znát každý lepší Windows admin (příkaz net byl ve Windows NT zřejmě od první verze, API NetUserAdd také, ty COM objekty jsou použitelné minimálně od NT4 a možná i dříve).

Uvedený příklad s nástrojem pro opravu DB jsem popsal proto, že pro zřídka používané funkce nestojí za to dělat GUI. Nicméně zkuste scanpst.exe a scanost.exe (je součástí MSO, a nebojte, oboje vyžaduje potvrzení po spuštění), obojí je v GUI. Stejně tak backup, restore a repair MS SQL Serveru děláte komplet v GUI. Je to rychlé a pohodlné. Pro offline defrag Exchange (který by neměl být třeba) ale GUI nejspíš pořád neexistuje.

CLI nástroje ve Windows jsou pochopitelně slabší, než na unixech, protože nejde o primární interface. Ve stutečnosti jsou ale daleko výkonnější, než si myslíte. Usuzuji tak z toho, že ani nevíte, jak založit uživatele z command line. Potom musím předpokládat, že neznáte ani rozšířené options příkazů for, if a set. Útěchou vám může být, že nejste zdaleka sám.

Administrace opravdu NENÍ task z "reálného světa". Administrace je obdobou údržby vozového parku firmy - tedy aktivita, kterou firma sice nechce dělat, a ráda by se jí zbavila, ale nemůže, protože auta musí jezdit, a systémy musí fungovat.

Pokud řekněme generujete faktury, budete to zřejmě dělat v IS, který to má na starosti. Kupodivu z command line neuděláte nic. Když budete faktury vystavovat ručně, skončíte zřejmě u Excelu nebo (v horším případě) Wordu. Kupodivu ani tady s command line nepochodíte. Když budete potřebovat vystavit ručně stovku faktur, nejlépe to půjde, když si vytvoříte template faktury v Excelu, a pomocí Excelu vytvoříte potřebné dokumenty, vyplníte do nich data z DB (pomocí VBA a ADO) nebo z Excelového sheetu, uložíte, vytisknete... Výsledek může v pohodě používat i osoba počítačů neznalá. Command line opět nula. Podobně s ostatními tasky z relálného světa. Až někdo si zarezervujete letenku z command line, dejte mi vědět ;). Bohužel je faktem, že na unixech z command line efektivně jen administrujete unixy.

Počet příkazů a shortcutů vimu tu někdo uváděl v této diskuzi (hledejte "spočítal", možná bez diakritiky, protože to byl unixák). Pokud se vám zdá, že "klasické" editory preferují řádek/sloupec, tak je neumíte používat. Vždyť můžete používat CTRL+kurzor pro pohyb po slovech, řádkách, odstavcích, stránkách, a se shiftem pro označování těchto jednotek (bohužel to řada lidí neumí, protože jsou neschopní se takovou trivialitu naučit). Celý soubor je CTRL+A, mezi závorkami se přechází CTRL+}, se shiftem se opět označuje výběr. Přiznávám, že matching závorek nepoužívám, protože vystačím s pohybem po řádcích a slovech - nestojí mi to za ty dva tři ušetřené stisky klávesy.

Vy rychle zeditujete konfiurák po roce učení se vi, za předpokladu znalosti jeho umístění a jeho obsahu. Já za všech okolností zkonfiguruji věc přijatelně rychle v GUI, a ušetřím si rok a více učení; místo toho se můžu učit principy (co chci dělat, nikoliv jakým příkazem to dělat), protože na těch opravdu záleží. GUI akce se samozřejmě dají automatizovat. Například pomocí Group Policy (nastavíte danou věc z GUI, pro vybrané skupiny uživatelů nebo strojů), nebo pomocí skriptů (včetně command line - viz reg.exe). Jde o to, abyste uměl používat možnosti, které máte, a hlavně o nich věděl. Unixy jste se musel léta učit, ale kupodivu to vypadá, že jste se při administraci Windows nenaučil 4 nejdůležitější příkazy.

Já bych to s tím GUI přirovnal k ovládání těch telefonů, které jsem tu popisoval (podívejte se, psal jsem i o tom, jak to omezuje zkušené uživatele). Účelem je, aby se běžné věci dělaly snadno. To, že neobvyklé věci nelze dělat triviálně, je holt už taková feature počítačů. Ani pro neobvyklé věci ale není třeba se učit vi, bash, awk, hromady příkazů, umístění a obsah konfiguráků, C, a kdo ví co ještě.

Autor vi možná byl na drogách, ale svého času to nebyl špatný interface. Dnes je dobrým interfacem Visual Studio, nebo UltraEdit. Chápu, že takové věci na unixech nejsou.

Jako hlavni nevyhodu ruznych 'klikacich' rozhrani vidim v tom, ze obvykle cloveka nepripravuji na reseni obtiznejsich uloh. Zatimco na unixu se clovek system nauci pouzivat na jednoduchych ulohach a tim ziska znalosti, ktere muze pouzit pro reseni slozitejsich uloh, V GUI systemech tomu tak neni - slozitejsi ulohy se tam resi uplne jinymi nastroji nez jednoduche ulohy a znalosti ziskane resenim jednoduchych uloh jsou k nicemu pro reseni obtiznejsich uloh, cimz vznika bariera.

Jako priklad uvedu zakladani uzivatele - v Linuxu pouziju adduser, kdyz chci vytvorit system, ktery zaklada uzivatele a dela spoustu dalsich veci na zaklade vlastnich konfiguraku, tak proste vyuziju znalosti adduser a spojim ji se znalosti obecneho skriptovani. Kdyz se ve Windows naucim pres GUI pridat uzivatele, a pak chci udelat system zakladajici uzivatele a delajici spoustu dalsich veci na zaklade vlastnich konfiguraku, tak k tomu ziskane znalosti o zakladani uzivatelu pomoci GUI jsou k nicemu a musim pouzit uplne jiny postup.

Ano, máte v podstatě pravdu, jde o nevýhodu GUI. Všimněte si ale, že je to první skutečná nevýhoda GUI, která se v diskuzi objevila.
Existují ale i jiné argumenty. 1) díky GUI můžete dělat věci bez znalosti stovek příkazů, ovládání vi atd; 2) s GUI se snadno naučíte, a se můžete soustředit na principy (co a proč), a ne na konkrétní příkazy (jak). Když se naučíte "co a proč", cestu "jak" už pak snadno najdete.

Když jsme u toho, unixy (POSIX) z nějakého důvodu nemají API pro přidání uživatele. Ono bohužel těch API chybí více. Například pro získání seznamu procesů, správu síťových připojení, správu deamonů atd. Řada věcí je POSIXem definovaná jen na úrovni utilit, a oficiální API neexistuje. Nepovažujete tohle za problém?

To jste si toho všiml brzo. Až když vám to někdo napsal "na plnou hubu". Protiargumenty opakujete pořád ty samé, napůl nesmyslné - co neustále máte s těmi stovkami příkazů? Žádné "stovky příkazů" umět nemusíte. Navíc přístup GUI funguje jen v případě, že to vaše "co a proč" je dostatečně jednoduché. Už vám to tu říkalo spousta lidí, včetně mě, a váš předřečník v tomto vlákně to konečně napsal tak jasně, že jste to dokonce pochopil a uznal. Ale pak jste zase nasadil svou ohranou písničku.

Ne, neexistenci přidávání uživatelů na úrovni API skutečně za problém považovat nelze, jelikož Unix definuje seznam uživatelů na úrovni textových souborů a pro práci se soubory má API dostatečné. Podobné se dá říci i o ostatních vámi zmiňovaných věcech. Z mého pohledu je to řešení mnohem elegantnější a úspornější, nežli těžkopádná řešení ve stylu Windows, snažící se pro každý problém poskytnout nějaké speciální volání API, který velmi omezuje možnost znovupoužitelnosti na základě podobnosti. Proto je taky Windows oproti unixům takové komplikované, těžkopádné, neprůhledné, nespolehlivé monstrum.

Na stránkách The Open Group (ti spravují známku UNIX, a speficikují POSIX compliance test) jsem našel 160 utilit. K tomu přičtěte utility specifické pro daný operační systém, pro X11 atd. Berte v úvahu, že pokud neznáte jméno konkrétní utility, tak jí nemůžete použít. Navíc je součástí seznamu vi, awk a pdobné lahůdky, které se člověk nenaučí za večer (typicky se unixy učí několik semestrů, a znalost studentů je přesto mnohdy tristní).
http://www.unix.org/version3/apis/cu.html

K tomu GUI jsem se vyjadřoval zde: http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/215784/ , viz předposlední odstavec. GUI je omezené stejně jako command line, uvádím tak příklady. To, že command line vám dává nějakou "absolutní svobodu", je jen velká iluze, která končí na první věci, na kterou vám někdo nepřipravil utilitu (viz rezervace letenek, nebo přehrání videa na systému bez podpory multimédií). A jak jsem konstatoval v linku, rozdíl je v principu hlavně v tom, že GUI vám umožní dělat ty předpřipravené věci opravdu jednoduše.

Jestli vám jako těžkopádné řešení připadá například mít API pro poskytování informací o systému (včetně seznamu procesů), ktežto jako elegantní vám připadá v případě potřeby prostě zavolat shell a příkaz ps, tak máme velmi odlišný pohled na věc. Obdobně když máte manaer deamonů (ve Windows service manager), tak můžete z jakékoliv aplikace zjistit stav služeb, zastavit je, změnit kontext ve kterém servis poběží, nastavit akci která se má provést v případě ukončení servisu atd. zdá se vám to nevýhodné proti klubku skriptů, které jsou na každém unixu jiné, a které prakticky vylučují jakýkoliv management služeb? Ono je to spíše tak, že unixy nezavedly věci, které měly zavést už před 25 lety. Uživatelé jsou obětí unix wars :(
Windows mají daleko čirší záběr funkcionality, než unixy, takže jsou logicky komplikovanější. Na druhé straně mají lepší interface, lepší a novější design, a díky tomu se nakonec pužívají daleko lépe (stejně jako komplikovanější auta nebo telefony se kupodivu používají lépe). Po letech používání unixů vám tyto možná přijdou průhledné, ale to mě Windows také. A spolehlivost... ta je dnes spíše o HW (a v případě Linuxu o nedodělcích, a špatných koknceptech typu OOM Killeru).

Jestli vám jako těžkopádné řešení připadá například mít API pro poskytování informací o systému (včetně seznamu procesů), ktežto jako elegantní vám připadá v případě potřeby prostě zavolat shell a příkaz ps, tak máme velmi odlišný pohled na věc.

To by samozřejmě bylo těžkopádné, proto to nikdo nedělá, a používá se tradiční kernelové API, které používá sám nástroj ps. :-) Více viz 'man 5 proc'. Mimochoem, jen tak bokem - co Vás vede k představě, že exec() spouští nehjprve shell a až potom spouštěný program?

"Tradiční kernelové API" bohužel není POSIXové, takže to bude fungovat tom unixu na kterém jste to použil, a jinde jen pokud máte štěstí. Otázkou je, proč tohle (a řadu dalších věcí, jako nahrazení pa-systému terminálových sekvencí, grafiku, správu deamonů a další) neřeší POSIX již 20+ let.

> Nepovažujete tohle za problém?

Neco ano, neco ne. To, ze nektere rozhrani neni standardizovano na urovni POSIXu, ale je standardizovano na urovni Linuxu (treba ziskani seznamu procesu a jejich parametru), za vyznamny problem nepovazuju.

Co se tyce toho vytvoreni uzivatele, tam je to proto, ze uzivatele vytvari administrator - ten to nebude volat z C, ale z shellu (protoze bude mit vlastni skripty pro vytvoreni uzivatele a na to navazane akce) a pro volani z shellu je optimalni.

Když už člověk píše SW pro platformu unixů, což je podle mě z obchodního i technickéo hlediska neštěstí, neměl by ho psát je jeden jediný konkrétní unix, nemyslíte?

Administrátor může používat SW, kterým bude uživatele zakládat. Navíc uživatele může zakládat HR oddělení, stejně jako jim dělá průkazky a karty, zařizuje školení, podepisuje s nimi smlouvy atd.

Administrátor může napsat skript nebo program, který otevře /etc/passwd a provede příslušné změny. Může k tomu použít awk, perl, C, Fortran, Pascal... a v každém z nich se to udělá stejně, jako jakákoliv jiná modifikace souboru. Připadá mi to mnohem logičtější a jednodušší, než u systémů, kde musí luštit, jaké volání API se k modifikaci systémové databáze uživatelů vlastně používá, jaké má parametry, v jakém souboru je k němu interface a jaké knihovny musí kvůli tomu připojit.

Pokud jsem si všiml, tak uživateli v /etc/passwd nenastavíte heslo. Také v /etc/passwd nezaložíte doménového uživatele. A pokud byste editoval soubor /etc/passwd na serveru (pro názornost zkusme editaci páté řádky, nikoliv přidání řádky k souboru), budete muset nějak zajistit, aby ho někdo nepoužil ve chvíli, kdy do něj zapisujete. Při čtení souboru během modifikace totiž systém nedostane kompletní obsah. A v případě, že se s někým sejdete při modifikaci souboru, zřejmě ztratíte část jeho obsahu. To jsou ale obecné problémy konfiguráků, které zdůvodňují použití API.

Přidávání uživatelů lze provést přes COM, a ať si vyberete COM, .NET nebo Win32 API, knihovny už máte.

budete muset nějak zajistit, aby ho někdo nepoužil ve …
Jo to api se už léta jmenuje vipw :)

Protože vám kašlu na záložky a formuláře, byť by byly zorganizované sebelépe! Při psaní textu se odmítám přehrabovat v záložkách a formulářích, jež jsou, jak sám uznáváte, koncipované pro většinového uživatele. Můj způsob uvažování je diametrálně odlišný od toho většinového uživatele. A nejsem sám. Při prohledávání umístění dané funkcionality v menu často musím přemýšlet ve stylu "kdybych byl autorem, kam bych to asi před uživatelem schoval". A když to nenajdu a prohledávám nápovědu, tak si zase musím říkat "kdybych byl autorem, jak bych to asi pojmenoval" když např. selže pokus o vyhledání staletí zavedeného typografického pojmu.

Tak to mi teda ty schopné sekretářky ukažte. Moje zkušenost se sekretářkami je taková, že jim nikdo neřekl, že existuje cosi jako "styl dokumentu" a že by to mohly používat. Pokud musejí editovat dokument, který této vlastnosti využívá, pak se připravte na lavinu stížností, že mají pokažený počítač, protože jim to tam skáče a mění písmo samo od sebe a támhle jim nejde ani odřádkovat. Průměrná sekretářka používá k formátování textu v MS Word tabelátor, mezerník a enter.
Co provádí váš finanční ředitel s Excelem pro mne údajně tak nepochopitelného by mne opravdu zajímalo.

Tak principiálně vzato je lhostejné, jde-li o Lisp či Basic. Obojí je založeno na psaní jazykových konstrukcí, neboli na příkazovém interface.

Pokud jde o ta NT, tak ani telefonát na technickou podporu tehdy nepomohl. Škoda, že jsem tehdy neznal vás, jistě byste mi s tím byl pomohl. Pokud si rozumíme, tak by vám mělo být jasné, že ani ten vámi navrhovaný příkaz daný problém řešit nedokáže. Jediné řešení by pravděpodobně bylo napsat utilitu v nějakém běžném programovacím jazyku a ten příkaz z něj volat analogií Turbo Cčkovského system() či přes API. Opravdu esence elegance a jednoduchosti...

Takže podle vás údržba vozového parku je nepodstatná věc? Nebo jak to mám chápat? Dokud na mnou zmiňovaném pracovišti běžel Unix, tak tam kvůli němu byl v podstatě jeden správce na půl úvazku. Po přechodu na NT tam už byli dva na plný a jejich výplata rozhodně byla za reálné peníze z reálného světa. Právě to, že se vám něco nechce, ale dělat to musíte, je samo o sobě dokladem, že jde o dostatečně reálný problém.

U faktur jste zase u příkazového rozhraní (VB). Neboli opět vyvracíte sám sebe a dáváte zapravdu mně.

U těch editorů mne opět podceňujete. To co tu tvrdíte pochopitelně všechno vím a než jsem začal používat vim, tak jsem toho i hojně využíval. Váš problém bych přirovnal k tomu, že vaše mysl se pohybuje v N rozměrném prostoru, zatímco moje v N+1 a proto neustále nejste schopen ze svého omezenějšího úhlu pohledu pochopit, co mám na mysli. Všechno co tu jmenujete lze podobně triviálně dělat i ve vi a řekl bych, že ty vaše klávesové zkratky jsou také odvarem toho nejzákladnějšího, co lze s textem při editaci dělat (mimochodem jste se je taky musel naučit zhlavy, pokud jste nechtěl neustále hrabat po myši a následně se přehrabovat v menu). Jenže se dá dělat ještě mnohem víc, jen vy si to prostě nejste schopen uvědomovat, nebo vám naučení se používání i jiných "triků" připadá zbytečně, neboť se toho dá dosáhnout i pomocí té "klasické" podmnožiny. No dá, ale dá to víc práce. Ovšem vám to evidentně nevadí - jsou lidé, kterým to vadí. A ti používají např. vi. Ovládání vi bych přirovnal k psaní všemi deseti poslepu nebo ke hře na piáno - když to neumíte, tak vám to může připadat komplikované (než rozluštíte noty, než najdete jednotlivé tóny k zahrání akordu, než si uvědomíte, který prst musí zůstat zmačknutý a který už má hrát zas něco jiného) - prostě nepředstavitelné, že by se tímto způsobem něco dalo zahrát. A vidíte, dá, a je toho hodně a tím víc, čím líp to umíte, neustále můžete zlepšovat svou techniku. Nikdo vás ke hře na piáno nenutí, ale vy se nepodivujte nad tím, že někdo věnoval čas, aby se to naučil, místo aby si jen tak zazpíval nebo zahvízdal, jak to třeba děláte vy, když máte náladu nebo se to povás chce - to je přeci tak intuitivní a jednoduché.
Ostatně i samotná klávesnice je tak neintuitivní, ta písmenka jsou na ní tak podivně rozházená; oč by to bylo jednodušší, kdyby to byla jen jedna řada 26 písmen od A do Z (+pár dalších znaků a řídících kláves). Začátečník by na ní okamžitě našel každé písmeno! Jen pochybuji, že by na tom písaři byli schopni udělat tolik úhozů za minutu, jako na současných klávesnicích.

Základní ovládání vi mi opravdu rok netrvalo. Řekl bych, že průměrně inteligentnímu jedinci na to stačí odpoledne. Pokud by vám to trvalo rok, tak to chápu, že by to pro vás bylo nepohodlné. Jenže pak byste měl vycházet z toho, že vaše schopnosti jsou značně omezené a že se tudíž najde spousta lidí, která vás mnohonásobně svými schopnostmi převyšuje a že tudíž ovládání šité na míru lidem na vaší úrovni jim zřejmě vyhovovat nebude. Neberte to prosím osobně, já také neberu vážně, že by vám zvládnutí vi trvalo rok.

Co pořád máte s těmi léty učení? Vám by trvalo naučit se ovládat Unix léta? Stejně jako vi? No to máte asi opravdu nějakou poruchu učení, jenže takovou poruchou já opravdu netrpím. A myslím, že zdaleka nejsem sám.

Ne, nemáte pravdu! Není to žádná "feature" počítačů. Je to pouze vlastnost vámi preferovaného typu rozhraní. Existují jiné typy rozhraní, které touto vlastností netrpí, nebo zdaleka ne v takové míře. A to je to, co stále odmítáte připustit.

Nedá se říct, že interface VisualStudia by mi vyhovoval. Že vyhovuje vám ještě neznamená, že musí vyhovovat každému.

Takže interface je špatný prostě proto, že se dobře používá běžnému většinovému uživateli? To mi přijde jako dost špatný argument. Stává se tedy pro vás interface vhodný právě tím, že se většině lidí používá špatně? A jak vypadá interface vašeho mobilu - je skvělý proto, že ho nikdo jiný neumí používat?
Když jsme u toho, váš způsob uvažování je odlišný proto, že jste strávil mnoho let tím, abyste si způsob uvažování odlišil, a to tím, že jste se memoroval hromady příkazů, učil ovládání vi, umístění konfiguráků, skriptovat v bashi, awk, perlu atd. Bylo by až s podivem, kdyby to na vás nezanechalo žádné následky. Já k tomu ale tvrdím, že jste mohl ušetřit čas a úsilí, naučit se malý díl konkrétních postupů, a dosáhl byste podobných výsledků. Nakonec vidíte, že se vyjma těch stovek příkazů stejně musíte učit ještě zacházet s GUI aplikacemi, protože v reálném světě s administrací unixů moc daleko nedojdete.

To, co popisujete, jsou špatné sekretářky (moc bych senedivil, kdyby psaly dvěma prsty). Je to jako bych vám psal, že restaurace je místo, kde od vchodu cítíte toaletu, po jídle skončíte v nemocnici, a když se budete tvářit nespokojený, obsluha vás zmlátí. Samozřejmě je možné, že si slušné sekretářky nemůžete dovolit, nebo je prostě nepotřebujete.
Finanční ředitel vám možná předvede ukázku lineárního programování (předpokládám, že víte, že s psaním kódu to nemá nic společného), citlivostní analýzu, předpovědi trendů, vytahá data z DB a bude s nimi dále pracovat. Makléř vám ukáže jak tahat kurzy z webu, používat custom funkce pro analýzu, a jak pracovat s databází. Dobrá účetní vám ukáže, jak generovat bez práce doklady z jiných dokladů, a jak ověřovat konzistenci dat, která by jinak musela procházet dlouhé hodiny ručně (špané účetní tráví většinu času činnostmi, které volají po automatizaci). Další vám ukážou, jak generovat v Excelu reporty vytížení pracovníků, knihy docházky z přihlašovacích dat, jak lze v Excelu vést projekty, plánovat zdroje atd.

O skriptování bych netvrdil, že jde o "příkazový interface". To byste nakonec mohl tvrdit, že Visual Studio je vlastně command line :)

V první půlce devadesátých let bych vám s Windows asi moc nepomohl, tehdy jsem měl raději unixy (než jsem zjistil, že totéž, levněji a pohodlněji lze udělat ve Windows; od té doby jsem je naštěstí téměř zcela zapomněl). Přidání uživatelů jste určitě mohl triviálně řešit spouštěním příkazu "net add user" z Excelu (tlačítko, na něm cyklus do while ... loop, který spouští funkcí shell(command) utilitu net). Minimálně od NT 4, ale nejspíš i dříve, fungovaly ty COM objektové příklady s CreateObject a GetObject. Vyjma toho jste mohl použít Win32 API pomocí Declare Function ve VBA makrech, nebo volat Win32 API přímo v buněk Excelu (CALL("Kernel32","GetTickCount","J!")).

Údržba vozového parku je věc, kterou firma dělat nechce, a jen na ní tratí zdroje. Ideální by bylo, kdyby žádná udržba vozového parku nebyla třeba. Bohužel nějaká třeba je, a tak se auta udržují. S administrací je to podobně: nikdo jí nechce, je to nutné zlo. To samozřejmě nevylučuje relativně vysoké výdělky na takovém trhu ;).
S přechodem na NT máme odlišné zkušenosti. Moje zkušenost je taková, že unixoví admini hledá do zelených obrazovek, cosi kutí, nikdo neví co (možná právě v lynxu píší root), je jich spousta, a požadavky firmy na IT jsou jim poměrně volné. Windows adminů typicky stačí méně, a při zřízení diskového sdílení se méně zaobírají kompilací, editací konfiguráků a integrací s doménou, takže zvládnou mimo jiné s klíčovým uživatelem navrhout strukturu adresářů, založit jí a nastavit na ní permissions. Možná je to pro ně menší zábava, než se samoúčelně rýpat ve strojích, ale dělají to, co firma potřebuje.

U faktur jsme u skriptování. Jak jsem psal výše, za chvíli budete tvrdit, že Visual Studio, nebo C++, jsou "příkazové rozhraní", a tedy vlastně command line :)

Ano, základy editace textu jsem se musel naučit. Konkrétně double click, používání menu, modifikátory Ctrl (pohyb po větších kusech), Shift (označení) a Alt (plus písmeno z menu). Vsadím se, že jste se to musel naučit také. Rozdíl je v tom, že jsem ušetřil ten rok učení se vi a stovek příkazů. Já se dokonce rozhodl, že se takovou příšernost, jako vi, prostě nechci nikdy naučit. Bohužel unixy v základní výbavě lelší editor nemají (co bych dal za MS edit.com), takže se umím pohybovat v textu, mazat, přepisovat a vyhledávat. Fuj, znečistil jsem se tím :(, já fakt nechtěl :((. Když mě bylo trapné tahat ty soubory na notebook, a editovat je v Notepadu.
Nějak mi není jasné, co více se dá dělat ve vi. Zlepšovat techniku můžete v čemkoliv. Já spíš myslím, že deonstrujete takový ten zápal pro věc, který vykazují modeláři u letadýlek, pejskaři u pejsků, nebo pedofilové u dětí. Samozřejmě to také znám, ale vi mě zrovna nebere.
Překvapuje mě, jak popisujete práci s vi. Já samozřejmě vídám lidi pracovat ve vi, ale nepřijde mi, že by byli efektivnější, než já. Nemají IntelliSense, takže s dnešními ukecanými jazyky by se upsali k smrti (zato jistě efektivně). Při editaci textů občas vidím, že udělají o eden dva údery na klávesnici méně, a někdy si naopak říkám "bum klávesa", a oni udělaji chord stylu "bum tss tss bum". Nedaří se mi v té rychosti přesně identifikovat akce, ale třeba zrušení řádku je rychlejší ve vi (esc dd), kdežto zrušení předcházejícího slova ve Wordu či VS (CTRL+backspace). Mám za to, že vi je pomalejší, když je třeba opakovaně přecházet mezi režimy. Nicméně buďme upřímní, dobře napsaný text není o rychlosti. Spisovatelé ani programátoři nepíší zdaleka tak rychle, jako sekretářky nebo písařky.

Klávesnice by na tom mohla být lépe. Například optimalizovaný layout Dvorak se neujal, i když je zjevně lepší, než QWERTY (nebo nedej bože QWERTZ, AZERTY, ITSUKE či QRATV). Klávesnice v jedné řadě není dobrý nápad, protože těch 101 kláves vedle sebe by nebylo nic moc, na hudební klávesnici to by bylo 8.5 oktávy :)

Zvládnutí vi na úrovni, kterou umí, mi zabralo několik desítek minut. Abych se ve vi naučil slušně pracovat, potřeboval bych minimálně několik měsíců. výsledkemm by bylo, že bych nemohl používat IntelliSense, neměl kontrolu pravopisu a gramatiky, a zabil spoustu času učením se něčeho naprosto zbytečného. To snad raději budu studovat dějiny (proč nám sakra neříkali na základní škole, že bájný Minotaurus vznikl pářením dámy jménem Pasiphaë s bílým býkem? o tom bych si tehdy udělal i referát).

Zkuste se podívat, jak budete z command line rezervovat ty letenky, nebo generovat faktury. Jak jsem říkal, na command line můžete efektivně leda administrovat unixy, a to ještě jen pokud dobře umíte konkrétní příkazy. Obecně cokoliv, co nemáte předpřipravené (ať ve formě GUI, nebo formou nějaké command line utility) se dělá obtížně, což uvidíte právě na té rezervaci letenek z command line. Obdobně pokud budete potřebovat řídit projekt (typicky za pomoci Gantt chartu), zjistit vývoj fluktuace zaměstnanců, nebo přehrát video, budete bez správné utility prostě nahraný - na command line, stejně jako v GUI. V tom je velká pravda, kterou většina uživatelů unixů nevidí - jejich naučené znalosti začínají a končí administrací unixů, což oni ve své slepotě vidí jako "můžu udělat cokoliv". Pointa je v tom, že GUI (omezené ve své podstatě obdobně, jako command line) vám umožní ty předpřipravené věci alespoň dělat jednoduše.

S unixy umím do té míry, že udělám cokoliv potřebuji. Nelíbí se mi ale ten koncept. Když to může být komplikované a uživatelsky nepřátelské, tak to tak udělejme, protože čím hůře pro uživatele, tím více je to unix. Když je to profi unix, přidejte "a k ceně na Wintelu připište nulu, ať vidí, že je to unix". V případě Linuxu zase člověk neustále naráží na hromadu věcí, které zjevně nefungují, jak by měly. Obcházet chyby je nakonec know how unixového admina. Například ty dlouhé názvy (mezery a diakritika) působí řadu problémů (viz též moje kritika perlu), i když jsou technicky zcela v pořádku, a každý unixový admin tedy ví, že jejich používání je vlasně děsná prasárna. Když takový název způsobí problém, je to samozřejmě chyba toho prasete uživatele, a ne daného systému či produktu, protože uživatel je vždy až na posledním místě snažení. Sorry, ale počítače jsou tu pro lidi, ne naopak.

Neustále mě překvapuje, s jakou energií jste schopen z názorů a omezených osobních zkušeností schopen destilovat absolutní pravdy... :o) Neustále něco o IntelliSense(TM), jako kdyby "doplňování kódu" a "IntelliSense" byla dokonalá synonyma, a zjevně si tudíž mylíte, že nic jiného než Visual Studio člověku doplňování nenabízí, přestože to není pravda, neustále tvrdíte, že Unixy mají problémy s diakritikou a mezerami v názvech souborů, pžestože to není pravda, a tak dál, neustále tvrdíte, že uživatelé Unixu nedokáží používat GUI, přestože to není pravda...

Doplňování nabízí více IDE. Ani nevím, jestli VS bylo první.
Unixy mají velké problémy s mezerami a diakritikou v názvech souborů. Viz fakt, že Oracle nelze nainstalovat do adresáře s mezerou v názvu. Velká spousta skriptů i alikací je špatně napsaná, takže na mezerách či diakritice zhavarují. A co se stane, když Qt aplikace dostane název souboru zapsaný v ISO 8859-2 (tedy dostane neplatnou UTF-8 sekvenci, přičemž Qt počítá se všemi názvy souborů v UTF-8, a převádí je do UTF-16), to mi také nikdo nevysvětlil.
Uživatelé unixů mě trvale přesvědčují, že s GUI neumí zacházet. Kolikrát jsem jen tady v diskuzi četl věci typu "s vi vyberu jednoduše text mezi závorkami, v GUI bych musel sundat ruku z klávesnice a označovat ho myší", a všichni mohutně přikyvovali. Kolikrát jsem tu četl věci typu "když chci v GUI přidat 30O uživatelů, tak se uklikám, kdežto na command line si napíšu skript", i když v GUI vám ty uživatele ze seznamu založím během pár minut.

Unixy mají velké problémy s mezerami a diakritikou v názvech souborů. Viz fakt, že Oracle nelze nainstalovat do adresáře s mezerou v názvu.

Oracle je Unix? Jestli ne, co z jeho vlastních problémů vyplývá pro Unix? Znám aplikace, které doporučují ve Windows, aby se neinstalovaly do adresářů s mezerou v názvu, znamená to snad, že i Windows mají velké problémy s mezerami?

A co se stane, když Qt aplikace dostane název souboru zapsaný v ISO 8859-2 (tedy dostane neplatnou UTF-8 sekvenci, přičemž Qt počítá se všemi názvy souborů v UTF-8, a převádí je do UTF-16), to mi také nikdo nevysvětlil.

V tom případě má uživatel závažně rozbitý setup a možná by bylo dobré, kdyby si spravil?

Uživatelé unixů mě trvale přesvědčují, že s GUI neumí zacházet. Kolikrát jsem jen tady v diskuzi četl věci typu "s vi vyberu jednoduše text mezi závorkami, v GUI bych musel sundat ruku z klávesnice a označovat ho myší", a všichni mohutně přikyvovali.

Jednak nechápu, jak můžete vidět, jak mohutně kdo přikyvuje, a jestli vůbec kdo přikyvuje, jednak mě udivuje, že dokážete ignorovat takhle jasný selection bias. Lidé, kteří se takhle ozývají, težko budou reprezentativní skupina, protože *tolik* uživatelů Vimu dneska zase není ani mezi unixáři. Na přidání tří set uživatelů - to jen tak mimochodem - není zapotřebí psát skript. Na to bohatě stačí one-liner tak na dvě minuty, a dokonce k tomu člověk ani nemusí být uživatel Vimu.

A vzhledem k tomu, že cílem není ani umět jenom GUI, ani umět jenom CLI (obojí jsou jen nástroje, ne náboženství), ale udělat potřebnou práci v co nejkratším čase, tak mi asi uniká pointa. Většina rozumných lidí včetně mně pro každý úkol používá nástroj, co je nejrychleji dopraví k cíli, jestli je to zrovna CLI, tak použijí CLI, a jestli to volá po GUI nástroji, použijí GUI. Z toho, jak zlomek uživatelů zakládá hromadně účty, extrapolovat, jak všichni uživatelé dělají všechno ostatní a jak snad i vaří kafe, mi přijde trošku odvážné.

> V tom případě má uživatel závažně rozbitý setup a možná by bylo dobré, kdyby si spravil?

Nemusi mit. Nevim jak QT, ale treba GTK implicitne ignoruje locale a predpoklada, ze jmena souboru jsou v UTF-8, i kdyz uzivatel ma jiny locale.

A i kdyby mel, tak to neni duvod, proc by mel program selhat, zvlaste kdyz s tim jmenem vnitrne vubec nemusi pracovat (kdyz ho treba jen predava z jednoho syscallu do jineho, jako treba filemanager, ktery kopiruje ci maze stromovou strukturu).

> jak snad i vaří kafe

Nevim jak na vareni kavy, ale na vareni caje se hodi oneliner:

sleep 180 ; while true ; do /bin/echo -e \\a ; sleep 1 ; done

Nevím jak GTK, ale Qt pracuje s UTF-16 wide chary. Veškeré souborové funkce je vracejí. U názvů souborů na disku se předpokládá, že jsou v UTF-8. Otázka je, co se stane, když jsou například v 8859-2, protože převod do UTF-16 nebude možný.

Samozřejmě i v GTK budete potřebovat název zobrazit, editovat, změnit příponu, a kdo ví co ještě. Problém je tedy v principu podobný.

Jádro problému je potom v tom, že se unixy nijak nestarají, jestli aplikace jede v UTF-8, nebo 8859-cokoliv. Pokud je aplikace stará a neumí Unicode, jede v 8859-cokoliv, a na disk píše názvy, které ostatní aplikace nepřečtou.

> Zkuste se podívat, jak budete z command line rezervovat ty letenky

Kez by se tak internetove obchody mohly ovladat emailem namisto pres web! Podobne, jako se treba objednavaji veci pres SMS.

> Jak jsem říkal, na command line můžete efektivně leda administrovat unixy, a to ještě jen pokud dobře umíte konkrétní příkazy. Obecně cokoliv, co nemáte předpřipravené (ať ve formě GUI, nebo formou nějaké command line utility) se dělá obtížně, což uvidíte právě na té rezervaci letenek z command line.

Hlavni rozdil je v tom, ze u command-line prikazu existuje glue (v podobe jazykovych moznosti shellu), ktery umoznuje efektivne kombinovat predpripravene utility a tim si snadno vytvaret nastroje vhodne pro konkretni situaci.

No, bohužel to nejde.

Ano, na command line můžete lepit. Bohužel mnohdy nemáte hotové nástroje pro běžné činnosti, nebo jsou ty nástroje velmi obtížně použitelné (viz třeba to vi), a bez znalosti konkrétního nástroje se o něm ani nedozvíte (command line vám ho na rozdíl od GUI neukáže). V důsledku toho se musíte hodně učit, abyste pak slepovat nástroje pro triviality. V GUI samozřejmě také můžete lepit, jak jsem ukazoval na příkladu Excelu, Corelu, AutoCadu, a řady dalších produktů. Jenom máte připravené nástroje, se kterými jednoduché věci děláte jenododuše. Na command line děláte vše složitě. A jak jsem psal, omezení jsou v principu stená - když nemáte vhodný nástroj (ať už v GUI nebo na command line), tak je další postup vždy obtížný.

Jenze je tu obrovsky prostor uloh, kterou v unixu vyresim elementarnim slepenim zakladnich nastroju, zatimco kdybych byl omezen na GUI, tak me nezbyde jen hledat presne nastroj na miru (anebo to vlastne vubec nemuzu udelat, kdyz bez znalosti konkretniho nastroje se o nem nedovim :-) ).

Já nemsylím, že by těch úloh bylo tolik. Navíc je otázka, kolik z těch úloh jsou neproduktivní "úlohy pro úlohy", typu administrace systému.

V GUI, jak jsem psal, máte možnost lepit nástroje. Nemyslím, že by byly možnosti slabší, než na command line. Máte k dispozici skriptování, COM objekty, a hromady nástrojů. Mimo jiné si můžete koupit komponenty. Ve výsledku když chcete vkládat čárové kódy do faktur, což neuděláte na command line ani v GUI, tak si koupíte COM komponentu, a za půl hodiny je můžete vesele vkládat pomocí makra, volajícího COM objekt. Na command line neuděláte ani tu fakturu (protože začnete a skončíte admnistrací systému), takže vás čárové kódy nebudou trápit.

Ve výsledku když chcete vkládat čárové kódy do faktur, což neuděláte na command line ani v GUI

Teď jsem napsal zypper in barcode barcode-devel a během deseti sekund jsem měl nainstalovaný generátor čárkových kódů jednak jako knihovnu, jednak jako konzolový nástroj. Proč by kvůli tomu měl člověk kupovat komponentu? :-)

To je případ, kdy vám někdo předem připravil utilitu. Když vám jí nepřipravil (třeba u té rezervace letenek), máte smůlu. Zkuste místo barcodů třeba OCR. Pro Windows koupíte OCR s COM a .NET interfacem během pár minut, a můžete ho použít v čemkoliv počínaje VBS a konče C# (někde mezi tím je také PowerShell). Obdobně můžete koupit medicínský imaging, integrační komponenty v podstatě pro cokoliv, atd. Slovo "koupit" není sprosté, protože autoři SW zaslouží odměnu.

Když jsme u toho, jak výsledné čárové kódy budete vkládat třeba do těch faktur? Zřejmě v GUI, tedy na Linuxu v OOo Calcu. Tam to uděláte jak (v Excelu máte VBA, a bar code generator bývá typicky COM prvek, tedy je to triviálně použitelné)? Nebo budete pracovat s fakurami na command line?

> Navíc je otázka, kolik z těch úloh jsou neproduktivní "úlohy pro úlohy", typu administrace systému.

Jedna z veci, kterou jsem si trivialne napsal v shellu, bylo tagovatko souboru mp3. Jeden skript prosel mp3 soubory v adresari a vygeneroval textovy soubor s tagama, ten jsem v editoru upravil a druhy skript upravil soubory podle tohoto textoveho souboru. Me takove rozhrani mnohem vic vyhovuje, nez vsechny editory tagu, ktere jsem kdy videl.

> Máte k dispozici skriptování, COM objekty,

V okamziku, kdy skriptujete, tak proste nepouzivate GUI, ale CLI. Z definice. A je uplne jedno, zda tim CLI je unixovy shell nebo interpret prikazu VBA.

Takže jste ochoten tvrzení zobecnit tak, že dobrým způsobem editace mp3 tagů je naučit se skriptovat bash, administrovat unixy, a pak si napsat skript? A doporučil byste tento způsob svým rodičům, nebo kolegyním v účtárně?

Kdybych už takovou věc chtěl provádět já, tak napíšu makro ve VBA, které slízne názvy souborů a tagy, uživatel si je může upravit, a pak je nacpe zpátky. Náročnost výroby bude podobná, zásadní rozdíl bude v tom, že výsledek bude schopný použít i člověk, který command line v životě neviděl (protože takových je bohužel většina).

Skriptování je algoritmizace, programování. Command line je taková ta věc s kurzorem, kde napíšete příkaz, stisknete enter, a on se provede. Jsou to dvě různé věci.
Smutným faktem je to, že naučit se skriptovat (programovat) je poměrně náročné, a tedy to umí jen profesionálové. A ani u těch není důvod, aby ztráceli čas psaním skriptů pro věci, které se běžně používají. Co se totiž dělá běžně, pro to už má být nějaký kód napsaný. Příkladem ze světa unixů budiž tasky při správě počítače typu založení uživatele, management swapu atd. V GUI jde v podstatě o funkčně stejný kód, jen vhodněji připravený pro uživatele.

> Takže jste ochoten tvrzení zobecnit tak, že dobrým způsobem editace mp3 tagů je naučit se skriptovat bash, administrovat unixy, a pak si napsat skript?

Ne. Dobre je umet nejaky skriptovaci jazyk, aby si clovek mohl automatizovat bezne delane ukoly na PC. To by melo patrit k zakladni znalosti prace s PC na urovni stredoskolskeho vzdelani. Jestli jde o Bash, Python ci VBA, to uz je skoro jedno.

> zásadní rozdíl bude v tom, že výsledek bude schopný použít i člověk, který command line v životě neviděl (protože takových je bohužel většina).

Proc by ten muj nemel byt schopen pouzit takovy clovek? klikne na ikonku, pusti se mu prvni skript, objevi se mu ikonka reprezentujici textovy soubor, klikne na ni a zedituje si ji v notepadu a klikne na dalsi ikonku.

> Skriptování je algoritmizace, programování. Command line je taková ta věc s kurzorem, kde napíšete příkaz, stisknete enter, a on se provede. Jsou to dvě různé věci.

V kontextu teto diskuse bych to chapal tak, ze jde o spor mezi dvema koncepty - ovladani pocitace pomoci formalniho jazyka (nepresne CLI) vs. ovladani pocitace mimojazykovymi prostredky (nepresne GUI). Pri techto definicich to CLI zahrnuje jak command-line v Unixu, tak editaci textoveho konfiguraku (at uz ve vi nebo v notepadu - nejde o editaci, ale o to, ze ten konfigurak je formalni jazyk), tak skriptovani v VBA.

> Skriptování je algoritmizace, programování.

Skriptovani je vetsinou algoritmu-proste

> Smutným faktem je to, že naučit se skriptovat (programovat) je poměrně náročné, a tedy to umí jen profesionálové.

Naucit se programovat na dobre urovni je narocne. Naucit se programovat na elemtentarni urovni nutne k prevazne vetsine skriptu je trivialni. Stredoskolaci se bezne uci v matematice resit goniometricke rovnice, to je IMHO obtiznejsi nez elementarni skriptovani dostatecne na mnoho uloh.

> A ani u těch není důvod, aby ztráceli čas psaním skriptů pro věci, které se běžně používají. Co se totiž dělá běžně, pro to už má být nějaký kód napsaný.

Pokud je uloha dostatecne jednoducha, jazyk dostatecne high-level a uzivatel ma jasnou predstavu, co chce, tak je casto proste jednodussi a rychlejsi si to naprogramovat, nez ztracet cas hledanim takoveho programu na Internetu a probiranim se mez mnozstvim podobnych programu aby clovek nasel takovy, ktery se dostatecne podoba tomu, co chci.

> Příkladem ze světa unixů budiž tasky při správě počítače typu založení uživatele.

Jiste, samotne zalozeni uzivatele je jednoduche, proto to je take elementarni operace v 'shellovem jazyku' (implementovana programem adduser). Mam treba server a kdyz tam zridim uzivatele, tak chci take zridit mu dve FTP konta (verejne a privatni), HTTP konto, emailovy alias, registrovat SSH klic a zridit soubor s hesly k nekterym sluzbam. Napsat skript, ktery udela vsechny tyto kroky, je trivialni (vyrazne jednodussi nez studovani nejakeho integrovaneho systemu pro spravu uzivatelu) a mohu si ho snadno upravit pro sve potreby. Pak pro zadani noveho uzivatele jen zavolam skript.

Naprostá většina populace skriptovací jazyk neumí, a nikdy umět nebude. Smiřte se s tím, prostě to tak je. Podobně naprostá většina populace není schopná postavit ani náznak technologické linky, nebo provést triviální chemický pokus. Když jsme u skriptování, je to samozřejmě algoritmizace. Už jen zřetězení instrukcí patří do této kategorie. Natož porovnávání, podmínky, skoky, cykly.

Ano, úprava MP3 tagů jak jí popisujete je možná. Ovšem to, co jsem popisoval já, bylo daleko komfortnější. A protože o uživatele jde až na prvním místě... Dál to znáte.

Kdepak, spor je mezi jinými koncepty. Já tvrdím, že počítače mohou dělat spoustu věcí, ale ty často prováděné věci musí být jednoduché. Vy tvrdíte, že má každý nejprve strávit hromadu času a úsilí studiem příkazů a konfiguráků, aby potom dělal jednoduché věci složitě. Praxe jasně ukazuje, kam jde vývoj. Nakonec předpokládám, že tenhle příspěvek vidíte v GUI, odpovídáte na něj v GUI, v GUI čtete a píšete maily, v GUI si zakládáte mailové účty, rezervujete letenky, píšete důvodové zprávy, vystavujete faktury, přehráváte multimédia atd. A z nějakého důvodu tvrdíte, že právě pro administraci systému jedině a pouze CLI. Nezdá se vám to samotnému trochu divné?

Nepodsouvejte mi něco, co jsem neřekl. Já jsem ani jednou v celé diskusi nenapsal, že GUI je špatný interface. Já jsem jen tvrdil, že se k některým věcem hodí lépe a k jiným hůře. Už po několikáté vám říkám, že je mi ukradené, co se líbí většině lidí. Já jim svůj interface necpu. Ovšem této většině se nehodlám přizpůsobovat, neboť svůj typ interface jsem zvládnul na takové úrovni, že nevidím ze svého pohledu v rozhraní pro většinového uživatele žádnou výhodu.
Víte, jaké rozhraní je podle mého názoru skvělé? Takové, s kterým se mi dobře pracuje. Nic víc, nic míň. Nežádám po něm, aby mi lehké věci ještě více ulehčovalo, ani aby se pokoušelo myslet za mě, dokonce ani aby mě nutně muselo ušetřit určité dávky úsilí k jeho pochopení. Nechci aby mě omezovalo, pokud k tomu není objektivní důvod. Chci, aby prostřednictvím něho bylo možné rychle a efektivně realizovat co největší množství mých myšlenek. Zkrátka aby bylo tak jednoduché, jak je to jen pro daný problém nutné, ALE NE JEDNODUŠŠÍ!
Všechno co píšete mne rozhodně nestálo takové úsili, jak by se vám mohlo zdát, ale zato se toto úsilí jeví ještě mnohem nepatrnější oproti tomu, co mi to přineslo. Já nevím, že se vám to zdá tak nepochopitelné, ale mně skutečně nedělá potíže se něco učit. Zvlášť když nejde o žádné biflování, ale učení se praxí.
Jinak do styku s obojím přístupem UI jsem přicházel už od prvního kontaktu s počítači. GUI představoval systém GEOS a zbytek to ostatní (např. CP/M). Jenže příkazový přístup mi prostě vyhovoval více.

Finanční ředitel ani makléř mi očividně nepředvedou nic, z čeho by mi spadla čelist na zem. Nebo co by nešlo udělat i skriptem ;-) A pravděpodobně efektivněji, neboť by se na každou věc mohl použít skutečně specializovaný nástroj - na statistiku, na lineární programování, na řešení okrajové úlohy eliptické rovnice, na Monte Carlo výpočet a co já vím co ještě...

No jistě že programování (ano, zatím ještě i to "vizuální") je příkazový interface :-) Snad proboha nechcete tvrdit, že ne.

Takže přes Excel... Máte pravdu, dostal jste mne. Přidávat uživatele do systému pomocí tabulkového procesoru by mne doopravdy nenapadlo.

No s tou údržbou to je pravda. Proto by měla být co nejlevnější a nejméně pracná.

Opravdu jsou naše zkušenosti rozdílné. Přechod na NT doprovázela neustále nažhavená linka na technickou podporu, jež se nám ovšem při veškerém úsilí na obou stranách drátu nedostávala. Nějakou dobu u nás přebýval i odborník přímo od MS, jehož nejčastější odpovědí bylo "to nejde". Žádosti o řešení provázání s ostatními produkty po týdnu snažení končívaly doporučením nahradit danou věc řešením od MS. Po zakoupení dané věci a marných pokusech o dosažení podobných funkcionalit, jako u předešlého softwaru, k nám byl vyslán expert MS číslo 2 (postupně až N), který konstatoval, že "to nejde". Pokud se přeci jen něco nakonec podařilo, bylo to obvykle podobně krkolomné řešení, jako to přidávání uživatelů přes Excel. Kromě toho se ukázalo, že starý HW nestačí novému OS. Takže po roce snažení jsme měli nové Windows NT a k tomu spoustu SW od MS, jenž jsme původně vůbec neplánovali kupovat, nový HW, rozpočet překročený asi tak dvojnásobně, přičemž nový systém v souhrnu nedosahoval schopností toho starého, jeho spolehlivost byla mizerná a při sebemenším problému bylo prakticky vyloučeno najít řešení svépomocí, a to i pro dva lidi na plný úvazek, prošlé příslušným školením MS. Pokud řešení existovalo, obvykle bylo realizováno expertem z MS, který si celý zákrok draze vyinkasoval a řešení provedl jakýmsi tajemným, s sebou přinešeným MS-interním SW, který ho bez znalosti administrátorského hesla pustil i do míst, o jejichž existenci se nezmiňují ani ty nejdetailnější referenční příručky (určené pro zákazníky).
Mimochodem - na jaké chemikálii byl závislý v MS člověk, jehož napadlo překládat jména excelovských funkcí do národních jazyků? ;-)

Proč za chvíli? Skriptování, C++ apod. snad není podle vás příkazové rozhraní? A co to tedy podle vás je? GUI asi ne.

Zase ta ohraná písnička o stovkách příkazů a roku učení. Nebudu se opakovat, komentováno dříve a ne jednou.
Bylo vyzkoumáno, že lidé obvykle nezmáčknou dvě klávesy najednou, ale že modifikující klávesa je stisknuta o chloupek dříve (často je ten chloupek třeba sekunda) a taky ji o chloupek později uvolní (tady ten chloupek bývá už podstatně kratší). Takže vaše CTRL+klávesa je často na stejné úrovni, jako u vi ESC+příkaz. S tím ovšem, že základní režim vi je editační, takže když zrovna nepíšu nový text, nebo když je příkaz kombinací více povelů, je editace rychlejší. Cvičení techniky u vi je přesně to, že čím dál méně přemýšlím nad tím, "jak" tu editaci provést (najet sem, označit odsud až tam, vystříhnout, najet támhle, vlepit, atd...) a místo toho se soustředím jen na to "co" chci provést (řádek se slovem "for" vrazit před řádek, kde je nebližší "=" nad ním; následující 4 řádky vykomentovat pomocí "//" a na předchozích pěti komentář "//" na začátku řádek naopak zrušit atd...).
IntelliSense už bylo komentováno tuším Rejpalem. Nehledě k tomu, že do vim se dá spousta věci doinstalovat či dodělat svépomocí, když mi to tam chybí. Inteligentní doplňování je jednou z nich.
To byste koukal, jak některým programátorům či administrátorům létají prsty po klávesnici! Já vím, mohli si ušetřit čas potřebný ke zvládnutím této schopnosti, kdyby důsledně používali GUI ;-) (aby ho pak mohli tisíckrát více ztratit ze stejného důvodu :-)

Klávesnice pro univerzální použití je dost těžké vymyslet, vzhledem k tomu, že každý jazyk má trochu jiné vlastnosti. Dvorak je stavěná na angličtinu, QWERTZ je snad výhodnější pro němčinu a u nás taky zdomácněla... vzhledem k tomu, že píši sice rychle, ale ne všemi deseti (tedy všemi deseti ano, ale ne správným prstokladem), tak nedokážu posoudit, jestli je z písařského hlediska lepší QWERTZ nebo QWERTY. Pokud je mi známo, tak uspořádání kláves bylo zvoleno s ohledem na technické možnosti psacích strojů (optimální střídání ramének s literami, aby nevznikaly "zácpy"). Nicméně to vše nemění nic na faktu, že lineární klávesnice podle abecedy by byla velmi intuitivní (ale dost nepohodlně prakticky použitelná).

Záleží, jak intenzivně byste v tom vi pracoval. K tomu dalšímu už jsem se vyjadřoval a jiní též - záleželo by na vás, chcete-li to. Jsem-li nucen něco napsat ve Wordu, pak kontrola pravopisu a gramatiky je tou první věcí, kterou vypínám. A tou úplně první je automatické doplňování, zvětšování písmen po tečce a naopak zmenšování písmen po velkém písmenu a podobné hovadiny, které mne neskutečně rozčilují. Protože stisknout shift když chci velké písmeno a uvolnit ho když chci malé ještě opravdu zvládnu.
Dějiny se klidně učte. Patří to k všeobecnému rozhledu. Nám zase na hodinách literatury nikdy neřekli, jakým způsobem vlastně v Eposu o Gilgamešovi tento tyranizoval své poddané a urucké ženy a proč tím tolik proti sobě popudil bohyni Aruru a jakým způsobem zvítězil nad bytostí Enkidu, poštvanou na něj touto bohyní. A proč tuto operaci s Enkiduem, kterou provedla Šamchat, nazývají polidštění. A jaké že to ta Šamchat uměla vlastně řemeslo...

Tak tedy o té rezervaci letenek - bylo jednou jedno letiště a na něm kdysi v 70. letech přišli na to, že by letenky mohli organizovat pomocí počítače. I koupil se počítač, terminály, operátorky se poslaly na školení a systém začal fungovat. V 90. letech se rozhodli, že provedou rozsáhlou modernizaci. Nový systém byl narozdíl od toho původního uživatelsky přívětivý a operátorky už taky nepotřebovaly zdlouhavé školení - firma ušetřila spoustu peněz a času. Studená sprcha přišla až ve chvíli, kdy se ukázalo, že produktivita práce operátorek výrazně klesla. Otázka zní - hádejte proč? ;-)

Já v Linuxu používám dlouhá jména s diakritikou bez problémů. Ty nastávají až v okamžiku, kdy to vypálím na CD nebo na flashku a chci se na to podívat ve Windows :-) Mýlíte se, když vymýšleli Unix, tak měli na mysli uživatele na prvním místě. Narozdíl od předešlých systémů. Jen holt nepředpokládali, že uživatel nebude ochoten vyvinout ani minimální úsilí se něčemu naučit a něco pochopit. Právě proto, že počítače jsou tu pro lidi a ne lidi pro počítače mne tak strašně rozčiluje, když se mě UI počítače snaží přechytračit, poučovat, navádět mě někam, kam si myslí, že já chci, ale přitom to tak není a tvářit se, že jinak to nejde a že já jsem ten blbej. A já jsem nucen s ním bojovat a hledat různé okliky, jak dosáhnout toho, co chci já a ne toho, co si počítač myslí, že chci (jako s tím přidáváním uživatelů přes Excel).

Takže vaše CTRL+klávesa je často na stejné úrovni, jako u vi ESC+příkaz.

Já hlavně nechápu, proč se absence CTRL+Backspace zmiňuje jako nevýhoda Vimu, když Cream to umí a v "plain Vimu" jsem si to nakonfiguroval a namapoval tak maximálně za patnáct sekund. Vim *umí* CUA, pokud to někdo chce.

Dějiny se klidně učte. Patří to k všeobecnému rozhledu. Nám zase na hodinách literatury nikdy neřekli, jakým způsobem vlastně v Eposu o Gilgamešovi tento tyranizoval své poddané a urucké ženy a proč tím tolik proti sobě popudil bohyni Aruru a jakým způsobem zvítězil nad bytostí Enkidu, poštvanou na něj touto bohyní. A proč tuto operaci s Enkiduem, kterou provedla Šamchat, nazývají polidštění. A jaké že to ta Šamchat uměla vlastně řemeslo...

Pche, Sumerové...ale takoví Egypťané, panečku. :o) Ale do svého Gardinera zatím jen smutně koukám. ;/ Chvílemi mi přijde, že na semitské jazyky jsem tupý. (Rozhodně víc, než na anglosaštinu.)

> Backspace je vlastně na terminálech to stejné jako Ctrl+H

Bylo, kdysy davno. Pak doslo ke 'Great backspace/delete shift' a moderni terminaly generuji ASCII 127 na backspace a nejakou escape sekvenci na delete.

Ctrl+H pro mazani znaku pred kurzorem nekde funguje, ale z uplne jinych duvodu nez driv - aplikace nekde emuluji stare chovani a maji na Ctrl+H nastavene mazani znaku pred kurzorem (zatimco mazani pomoci backspace a driv pomoci Ctrl+H je reseno na urovni terminalove vrstvy v jadre).

Aha, zmatl me pritomny cas v te vete.

Jů, tys' nám povyrostl... :-)))

?

U systému terminálů v unixech mi nikdy nedošlo, proč nebyl zrušen před 20 lety. Základním interfacem by mělo být API pro pár akcí typu přesun kurzoru, změna barvy popředí a pozadí, výpis textu, a možná vyplnit pole znakem dané barvy. Místo toho mají unixy definice desítek až stovek terminálů, ke každému terminálu hromady sekvencí, backspace/delete problém, a výsledkem je neuvěřitelný bordel a hnus. Asi i proto řada aplikací "oficiální" definice terminálových sekvencí ignoruje, a managuje si je po svém (třeba mc). Výsledkem je ale ještě větší chaos.

Bohužel váš oblíbený interface vám připadá skvělý až poté, co jste se naučil ty stovky příkazů, včetně ovládání vi. Veliká investice, jejíž jediným výsledkem je to, že jste schopen administrovat unixy (tj. přidávat a odebírat uživatele, měnit ACL, a analyzovat logy). Věci z reálného světa nakonec stejně musíte dělat v GUI, se kterým pak typicky neumíte efektivně zacházet. U toho mi tvrdíte, že vás podceňuji, ale na druhé straně vás překvapí ukázky použití GUI. Je mi ale jasné, že když jste provedl tak vysokou investici zcelku zbytečně, musíte nyní najít způsob, jak jí obhájit.

Ty stovky příkazů jsem někde popisoval - v Single Unix specification je jich uvedeno 160, a to včetně těch vysoce obtížných typu vi a awk. K tomu přičtěte utility pro managament daného OS, X11 serveru atd.

Jak jsem právě napsal o kus vedle, programování je algoritmizace. Command line interface je věc s kurzorem, kam napíšete příkaz, stisknete enter, a příkaz se provede. Jde o dvě různé věci.

O Excelu jsem tu psal opakovaně i v této souvislosti. Proč ne přes Excel? Umožní vám zapsat data, a umožní nad ně pověsit skript. Je to jednoduché, efektivní, a nesmírně silné (i ve srovnání s command line). Výsledek lze zabalit tak, že ho může používat i idiot. Co tomu chybí? Excel je z mých oblíbených aplikací.

Ano, máme odlišné zkušenosti. Jenom zkusím z vašeho vyprávění vypíchnout několik věcí, které se mi nezdají. 1) Microsoft ČR má odjakživa naprosto minimální počet zaměstnanců, a okolo toho spoustu partnerských firem. Velká firma totiž není moc flexibilní (starý známý problém, viz IBM), a malí pružní partneři to dokáží kompenzovat; je to velmi úspěšný model. Z toho důvodu považuji za nepravděpodobné, že by k vám přišel někdo přímoz MS. 2) Protože se v oboru pohybuji nějaký pátek, tak vím, že interní SW, který vás pustí do utajených míst, kde můžete provést tajemné věci, je nesmysl. Jde pouze o neznalost na vaší straně, a o neochotu vám ukázat, o co opravdu jde.
K tomu "nejde": systémy typu Windows umožňují dělat běžně věci jednoduše. Méně běžné věci jsou o dost složitější, což je na command line stejné (jak jsme si ukázali - nemáte utilitu, tak končíte, stejně jako v GUI). Pokud jsou věci složitější, lidí rádi říkají, že "to nejde". Také to říkají v případě, kdy daná věc není dobrý nápad. Například pokud chcete, abyste na stroji měl nasdílené adresáře v závislosti na přihlášeném uživateli (na unixech s představte NFS exporty podle toho, kdo je přihlášený na konzoli). Spousta lidí bude říkat "to nejde", protože je to z jejich hlediska blbost. Ti, kdo umí (a těch je na světě minimum - zřejmě máte tu čest se mezi takové lidi počítat) vědí, že to jde, a jak to jde. Pak je otázkou, jestli řeknou "to nejde", protože je to blbost, nebo jestli řeknou "myslím, že je to blbost, ale za cenu XYZ to máte mít". Když totiž řeknou to druhé, tak vás zřejmě zákazníka zavedou do bažin jeho vlastních nesmyslných a protichůdných požadavků, ze kterých se pak budete těžko vymotávat.

A když jsme u zkušeností, tak přidám svojí zkušenost. V organizaci, kde jsem pracoval, řádila společnost Digital Equipment Corporation. Proto vše jelo na Ultrixu. Když se zkoušely PC servery tehdy s Novellem a Lantasticem, upozornili pánové z Digitalu odpovědné pracovníky, že tyhle PC servery jsou pěkný šmejd, a díky tomu mohou způsobit blíže neurčené problémy na síti, které by se potom odstraňovaly velmi draze ("víte, měli jsme již takový případ... velmi drahé..."). Tomu se říká FUD, a jde o formu biče. Pravidelná pozvání pana IT ředitele na kongresy do USA potom byly jistou formou cukru. Doba se pohnula, přišlo OSF/1 (rozdílem byl hlavně xterm a xclock), a s ním nová verze file serveru Digital Pathworks. Servery byly o řád dražší, než PC servery, a nakoupilo se jich cca 20, aby mohly být potroušené po té naší domovině, a složit jako file a mail servery. Bohužel klienti Digital Pathworks se od serveru samovolně odpojovali, což u tehdejších DB systémů založených na FoxPro a dBase IV nedělalo moc dobrotu. Digital následně vydal asi 10 patchů, které měly jako jediný výsledek to, že se problémy logovaly (některé revize problém logovaly, jiné ne, občas se drobně změnila hláška). Protože tehdy nebyly všechny servery síťově propojené (kvůli mailu se ale propojení časem plánovalo), těch cca 10 revizí znamenalo pro adminy hromady cest po republice. S příchodem Windows 95 u Digital Pathworks dokonce fungovaly dlouhé názvy, ale bohužel bez češtiny. Na potvoru české Windows 95 zakládaly nový adresář vždy jako "Nová složka", a ten Pathworks sežraly, ale už nevrátily, takže na síťových discích byly desítky až stovky adresářů "Nová složka (číslo)". Podpora Unicode předpokládám nakonec ani nepřišla. Samostatnou kapitolou byl vývoj serverových aplikací, přece jen FoxPro není ideální prostředí. Ovšem Oracle Forms k němu má také daleko (krásný terminálový interface, zastánci unixů by si přišli na své). Vyjma šílené ceny se jako problém ukázala náročnost vývoje. Co trvalo ve FoxPro napsat jeden den, trvalo v Oracle Forms minimálně týden, ale spíš déle. Výsledné aplikace byly samozřejmě výrazně méně komfortní, a uživatelé je odmítali používat (nebylo jim to nic platné). Vzniklo oddělení o cca 10 lidech se zkušenostmi se sálovými počítači (programátoři, vedoucí, sekretářka, testerka), které non-stop vyvíjelo informační systém, nutno říci bez velkých úspěchů. Mezi tím se staly populárními prostředky typu Visual Basic, MS Access, Delphi, Oracle for Widows, MS SQL Server; file servery a print servery se dávno přesunuly na Windows NT, zahraniční firmy v ČR běžně jely NT 4.0. Nicméně Digital se statečně držel, a za směšně nevýkonné unixové stroje se platilo o řád více než za stroje na Windows. Několik místních poboček bylo examplárně potrestáno za nákup PC serverů značky Compaq.
Zbytek té historie by byl asi dost nudný (včetně neprokázaných povídaček o úplatcích), nakonec jsem prostě utekl. Uvádím to jako svoji zkušenost s dodavateli unixových systémů, a s unixy jako takovými. Jestli to považujete za odstrašující, nejste sám.

Lokalizace funkcí v Excelu je dost drsná věc. Naštěstí se mě týká jen na jednom stroji, kde jsem si omylem objednal českou verzi MS Office :(. Lokalizace je pro běžné uživatele potřeba, zvláště v ČR kde lidé jazyky neumí, ale pro mě prostě není. Pravda, k anglickým verzím Windows i Office se dají nainstalovat lokalizační moduly, což potěší mezinárodní firmy.

Osobně nemusím cvičit techniku vi, abych nemusel přemýšlet nad editací textu stylem "najet sem, označit odsud až tam, vystříhnout, najet támhle, vlepit". To jsou přece po čase naprosto automatické úkony, které vůbec nevnímáte.
IntelliSense bylo komentováno, a závěr byl ten, že vim toho nenabízí zdaleka tolik, jako VS. Navíc osobně nevidím důvod, proč bych měl dopatlávat takovou věc, jako automatické doplňování. Na to snad nikdo nemá čas.
Mě také létají prsty po klávesnici, a opět k tomu nepořebuji command line, ani vi. Jindy mi létají prsty po myši.

QWERTZ klávesnice u nás zdomácněla proto, že se k nám původně vozily německé psací stroje, kde byla jedna typa nahrazena mrtvou klávesou háčku/čárky. Zatím co na malá písmena a české umístění závorek, uvozovek apod jsem si zvyknul, na QWERTZ ne. Samozřejmě anglický text, kód a administraci vždy jen na US layoutu. Lineární klávesnici můžete vidět u blokových klávesnic s abecedním pořadím, zákazníci to nemají rádi.

Když píšu něco ve Wordu, kontrolu pravopisu a gramatiky samozřejmě používám. Je dost trapné mít v textu překlepy. Automatické doplňování a opravy mají někdy smysl, a jindy ne. Například nahrazování uvozovek za okrouhlé je velmi užitečné. U těch méně užitečných je zcela zásadní, aby šly rychle a pohodlně vypnout. Od uvedení smart tags v Office 2003 to naštěstí jde.
Ano, Epos o Gilgamešovi je zrovna poměrně zábavný. Bohužel školy mají neuvěřitelný talent měnit víno ve vodu. Když jsme například u práva první noci, která má i v na našem území jistou tradici, tak je to věc pohledu. Z hlediska držitele tohoto práva to může být poměrně zajímavé, a kdyby bylo drženo i dnes, stálo by za úvahu nechat se zaměstnat v komunální sféře. Přece jen práce, to jsou i jiné benefity, než peníze. Stravenky, auto, mobil, právo první noci... Ke stáru už jsem pravda monogamní, takže bych dal přednost soukromé sféře. Hrozná je naopak představa, že by nešlo o právo, ale povinnost. No a z hlediska ženy? To bych asi spáchal sebevraždu. Z hlediska muže takové ženy? To by určitě skončilo úplatkem nebo vraždou.

Kupodivu letištní přepážky dnes fungují převážně v GUI. Samozřejmě problémem je interface navrhnout tak, aby byl dostatečně efektivní. Když se to ale udělá správně, nemusíte operátory tak dlouho školit, operátoři dělají méně chyb, a efektivita práce je vyšší. Zdůrazňuji, že může být lepší dobrá command line, než mizerné GUI. Na Linuxu to je vidět dost často.

Vy asi s řadou věcí nemáte problémy. Mě se pravidelně stávalo, že skripty i aplikace havarovaly na názvech souborů obsahujících mezery. Jako příklad jsem uváděl instalaci Oracle, Oracle klienta sqlplus, a velké procento skriptů.
Data na flash disk zřejmě ukládáte na FAT. FAT má dlouhé názvy v Unicode (i na Windows 9x), takže s nimi není jediný problém. Na Linuxu ale není výjimkou vidět experty, kteří si přimountují FAT s code page ANSI1250 (asi někde tu zkratku uviděli, a chytli se toho), a pak na ní zapisují názvy souborů v UTF-8 nebo 8859-2. Výsledkem je, že se znaky v UTF-8 nebo 8859-2 považují za znaky v ANSI 1250, které se pak převedou na Unicode UFT-16. Uznejte ale, že tohle není problém Windows, ale 1) problém uživatele, 2) problém unixů a jejich zacházení s Unicode.
U CD je to zřejmě podobný příběh. Joliet extension používá file names v Unicode, a není důvod, aby dlouhé názvy nefungovaly. Typické chyby neznám, protože jsem na Linuxu nikdy CD ani DVD nepálil.

Jak jsem psal již dříve, chápu, že uvažujete jinak, než jak je navržené GUI. Ale vy zase chápejte, že jste se léta snažil uvažovat jinak, a byl jste holt úspěšný. Lze tedy předpokládat, že vám vyhovují věci, které jsou pro zbytek světa naprosto nepoužitelné. Otázkou je, jaké z toho vyplývá poučení. Třeba "netrapte se učením vi, protože po pár letech takové deformace budete tak mimo, že vám běžné GUI bude připadat jako příšerně neergonomické"?

Ten závěr je subjektivní, ale připadá mi, že o něm není pochyb.

Mame stesti, ze pred tisici lety jeste nebyli usability experti. To bychom asi dodneska psali obrazkovym pismem.

:-D

Já jim říkám "Jů, zabili to!"-experti... :o)

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Tak zrovna Číňané přestali psát obrázkovým písmem před pěti tisíci lety. Japonci a Korejci ho nejspíše nikdy ani nespatřili.

Ehm, beru to zpátky. To Egypťané napsali zřejmě první ideografické znaky (nikoli pouhé "obrázky") ve třiatřicátém století před naším letopočtem, již v předdynastické době. Je to nález Güntera Dreyera, pouhých deset let starý, takže se možná do učebnic ještě ani nedostal, ale posunul laťku prvenství ve vynálezu regulérního písma do takového dávnověku, že ani Sumerové se na to už nechytají. U Číňanů to asi proběhlo ještě o nějaké to tisíciletí později. V čínské chronologii se vyznám mnohem méně, než v té egyptské. :-)

Já měl na mysli dnes užívané logografické systémy. Samozřejmě historie je historie, čest památce hieroglyfů, čest památce unixů.

> čest památce unixů.

Jež byly dle vašeho názoru překonány čím?

VMS, OS/2, Windows řady NT, MacOS (který má pravda díky technologické idiocii společnosti Apple unixové vnitřnosti, protože sama nebyla schopná dát dohromady nic lepšího), do budoucna Singularity.

Já jsem tušil, že vaše odpověď vzbudí úsměv. Nezlobte se na mne, ale tvrdit, že OS/2, Windows NT či MacOS překonávají Unix je skutečně pošetilé. Naopak si troufám tvrdit, že v podstatných rysech nepřinášejí vůbec nic nového a pokud ano, tak je to snaha originálně řešit věci, jež vyřešili autoři Unixu dávno před autory vámi zmiňovaných produktů. Nutno ovšem říci, že autoři Unixu se toho zhostili s mnohem větším úspěchem.
Já netvrdím, že Unix je zázrak všech dob a nic lepšího nemůže být dáno dokupy. Ovšem OS/2, NT, či MacOS mohou Unixu konkurovat jen ztěží, a už vůbec nemají ani v nejmenším potenciál na jeho překonání. Ze stínu Unixu nemají a nikdy nebudou mít šanci vystoupit.

Totéž můžete úspěšně tvrdit o unixu, který také nepřináší nic zásadně nového. Vždyť Unics byl započat jako koncepčně zjednodušené pokračování Multicsu.

OS/2, Windows a Mac změnily svět, a dostaly počítač na každý stůl. Unixové workstation s vi se to kupodivu nepovedlo. Windows řady NT navíc přišly s výrazně novější technologií (včetně zabezpečení, GUI a grafiky), a porazily unixy na trhu. Můžete si všimnout, že Windows dávno počtem instalací daleko předčí unixy (samozřejmě i na serverech).

Z historického hlediska jsou dnes unixy ve fázi posledního výprodeje zdarma. Jak jinak chcete říkat tomu, že tržní podíl unixů od uvedení NT neustále padá, a situace došla tak daleko, že je unix (Linux) už dokonce zdarma? A co vás více přesvědčí, než fakt, že lidé dávají přednost placenému OS před unixem zdarma?

Z historického hlediska jsou dnes unixy ve fázi posledního výprodeje zdarma. Jak jinak chcete říkat tomu, že tržní podíl unixů od uvedení NT neustále padá, a situace došla tak daleko, že je unix (Linux) už dokonce zdarma?

Unixy byly odsouzené ke ztrátě velké části tržného podílu především proto, že jejich dodavatelé byli arogantní náfukové. Proto ani Windows, ani Linux neměly problém se zabráním slušné části serverového trhu. Podobně to přeci dopadlo i na poli hardwaru - kdo vyloženě nemusí, koupí PC server, a k iSeries nebo podobným strojům se sahá vlastně v případě nutnosti.

A co vás více přesvědčí, než fakt, že lidé dávají přednost placenému OS před unixem zdarma.

A o čem by nás měla přesvědčit skutečnost, že firmy vyžadují určitou úroveň podpory, který je placená? To zní skoro jako tautologie. :-) To u systému zdarma samozřejmě nedostanete, pokud si to nezařídíte třeba u dodavatele HW, jak to nabízí Hewlett-Packard s Debianem. Jinak firmy většinou samotný OS kupují.

Unixy především zastaraly. V půlce osmdesátých let to ještě pořád byly super systémy. Tehdy byl čas na zavedení managera deamonů, API pro správu systému, postupné zavádění grafiky, zrušení předpotopního systému terminálů, implementaci bezpečnostních features, a opravu bezpečnostních děr (jistě pamatujete vlnu buffer overflow útoků). Díry se podařilo zalátat (byť je jich pořád požehnaně v celém SW průmyslu). Bohužel reforma unixů nepřišla, a výrobci raději bojovali o velké peníze, které z unixy přinášely. Potom přišel MS, a nabízel stroje se snadnou správou, novější technologií, a za desetinu ceny či levněji. Kupodivu vyhrál, přes uplácení a šíření FUD ze strany výrobců profi unixů.

Intel HW je masově produkovaný, a ty objemy jsou takové, že cenou nemůže konkurovat prakticky nikdo. Unixy proto zbyly prakticky jen tam, kde se nic jiného nebylo možné nasadit. V první polovině 90. let to byly velké DB, v druhé polovině 90. let už jen 64-bit stroje. A dnes existuje jen málo aplikací, na kterých by bylo technicky nutné nasadit ne-Intel HW. Unixy tedy na pár místech pořád musí být, na některých místech je drží zvyk, a na dalších místech nulová pořizovací cena.

Podpora obecně není schopná zaplatit vývoj. Aby se totiž vybralo tolik peněz, jako prodejem licencí, musela by být podpora neúměrně drahá. Pokud by si kupil podporu každý desátý zákazník (dost optimistické číslo), musela by být průměrná cena podpory 10x vyšší, než cena licence SW, abyste měl stejné výnosy (ceteris paribus); a k tomu ještě přičtěte cenu té vlastní podpory. Samozřejmě podporu může u open source poskytovat každý, a nemusí platit drahý vývoj, takže by vaší drahou podporu nikdo nekoupil.

Na kolik stolů dostal počítač OS/2, systém, který Microsoft opustil a IBM úspěšně pohřbila? ;-)

to je dobrý point ;)

To bych tedy v žádném případě netvrdil. Buď neznáte Unix, nebo Multics. To byly dva naprosto odlišné projekty. Především po koncepční stránce.

No zajímavé kriterium kvality OS. Neřekl bych, že to byla zrovna zásluha kvalit MS-DOS či Windows, co dostalo počítač na každý stůl. A OS/2 jste zřejmě mínil jako vtip. V tom případě by se dalo říct, že software ZX Spectra a C64 svými kvalitami drtí Unix, jelikož jen C64 se prodalo 30 milionů. To se totiž unixové stanici taky nepovedlo. A řekl bych, že se to nepovedlo ani IBM PC s MS-DOSem či MacOS na Applech.

Windows NT bezpečnější než Unix? Že by další pokus o vtip? GUI bylo převzaté z Windows 3.1.

Proč by Linux nemohl být zdarma, když byl od samého počátku produkován nadšencem pro potěšení jakožto freeware? Jak to souvisí s marketingem? Víte, tohle opravdu nefunguje jako když má Kaufland výprodej ;-)

Multics: protection rings (dokonce 8 jich bylo), shared memory multiprocessor, memory mapping, dynamické linkování, access control listy, deamony, terminálové UI, hot swapping (aka on-line reconfiguration), podpora více procesorů, hierarchický FS, symlinky, kvóty, nebyl psaný v ASM, měl monolitický kernel. Co tedy unix přinesl tak převratně nového? Byl jste to vy, kdo psal o NT : "v podstatných rysech nepřinášejí vůbec nic nového a pokud ano, tak je to snaha originálně řešit věci, jež vyřešili autoři Unixu dávno před autory vámi zmiňovaných produktů". Opravdu vám nepřipadá, že totéž lze říci o vztahu unix-multics?

NT měly od začátku access control listy, a od začátku používaly challenge/response autentizaci. Unixy v té době používaly systém rwx bitů, telnet, FTP, a NFS "zabezpečené" UID a GID.

Linux není vyvíjen nadšenci zdarma. Jak jsem uváděl v jiných diskuzích, například Linux Foundation dostává miliony dolarů ročně od společností IBM, Oracle, Intelu, Fujitsu, AMD, Motorola a dalších. Vývoj Firefoxu zaplatil částečně Netscape, částečně AOL/Time Warner, a nejvíce zřejmě Google. Vývoj OpenOffice platí Sun Microsystems, a nalil do něj v přepočtu miliardy korun. To vše jsou fakta, která lze lehko dohledat (zdroje jsem uváděl i tad na rootu v dikuzích).

"Co tedy unix přinesl tak převratně nového?"

Praktickou použitelnost? Aneb proč tedy pracovní stanice a servery v osmdesátých a devadesátých letech okupoval spíš Unix než Multics?

Já měl za to, že praktickou použitelnost přinesly právě ty Windows, OS/2 a MacOS. Ale řeč byla spíše o technologii.

Jde spíš o to, že Multics přinesl spoustu skvělých nápadů, ale prakticky nikdo ho nemohl používat. Na začítku vývoje měl na hardware takové nároky, že pokud člověk neměl high-end mainframe, měl smůlu. Pak z toho pár firem vycouvalo a nakonec z toho rozhodně obchodní trhák nebyl. Ostatně byl velmi neohrabaný. Třeba PL/I opravdu nebyl zrovna brilantní nápad. Dnes bychom s kompilátorem pro něco takového asi neměli takové problémy - ostatně dnes jsou lidé ochotni používat i C++ - ale to i DEC měl se svým BLISSem víc rozumu, přestože BLISS nakonec porazilo Cčko (což mi je trošku líto).

To všechno je samozřejmě pravda. Ale nic to nemění na to, že Unix je Multicsem velmi inspirovaný. Když mi někdo tvrdí, že Windows NT nepřinesly v podstatě nic radikálně nového, nejvýše nově řešily věci které unixy již nějak řešily dříve, nemůžu nepoukázat na to unix vs multics.

...že Windows NT nepřinesly v podstatě nic radikálně nového...

V mnoha směrech nic nového nepřinesly, spíš uřezávaly. Ale protože ten systém, ze kterého bylo uřezáváno, byl VMS, tak jim to na použitelnosti jen prospělo. (Pokud Unix považujete za systém, který se člověk musí rok učit, než přidá uživatele, co řeknete na VMS? :o) VAX jsem svého času bez manuálu ani nedokázal nabootovat...) Já tedy WinNT nepovažuju za špatný systém, to jen aby nedolo k nedorozumění. :-)

VMS jsem viděl jen zdálky. Původně mě zajímaly 8-bity, CP/M a technologické počítače, od roku 86 PC, od roku 90 unixy, od roku 94 postupně Windows.

Jo a díky za ten poslední odstavec, budu na něj odkazovat lidi na Živě, až se budou smát, že linuxový kernel flikují studenti po večerech. Známému expertovi na Windows snad budou věřit. :o)

Nemusí věřit, mohou se podívat na členy Linux Foundation, a podívat se na výši členských příspěvků (Platinum Members USD 500 000 ročně).

> Linux není vyvíjen nadšenci zdarma.

Podle rozboru od Grega KH je zhruba 20 % vyvojaru nadsenci, 80 % placeni firmama.

> Linux Foundation dostává miliony dolarů ročně

Zrovna Linux Foundation mnoho vyvojaru neplati, vetsina vyvojaru je primo placena tema firmama.

To je možné. Jenže je otázkou, jaký rozsah kódu kolik commitů zaplatí firmy, a jaký napíší nadšenci, kolik je to v počtu řádek, které věci jsou důležité a které jsou vata, atd.

Vidíte, miliony dolarů, a podle vás je to jen malá část financování.

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Editor vi máme proto, že v sedmdesátých letech byla taková potřeba, viz například editace souborů přes 75 Bd linku. Dovolím si tvrdit, že dnes jde o přežitek.

Nie je to prezitok. Efektivnejsie je editovat vo VI. Ja som editorov vyskusal viac a VI vychadza najlepsie. To o VI nic nevies tak sa k tomu nevyjadruj.

Netykáme si.

Také jsem zkusil více editorů. Ty, které nemají vizuální interface, jsou samozřejmě vyřadil. Jak jsem několikrát psal, pokud ve vi/vim neznáte konkrétní příkaz, tak danou akci nemůžete použít (a zůstane vám navždy utajená). V GUI stačí vědět, co chcete udělat, a najdete to v menu. Pokud to v menu hledáte často, naučíte se zkratkovou klávesu. Ve výsledku rychle a efektivně uděláte to, co potřebujete často, a s trochou hledání uděláte věc, o které přesně nevíte jak se dělá. Přechod z fáze "hledám to" do fáze "znám to" je přitom automatický a bezbolestný. Srovnejte s vi, které jste se musel pracně učit, a abyste ho používal "intuitivně", musel byste v něm pracovat léta (berte také v úvahu, že mimo svět unixů není editace textových souborů hlavní náplní práce admina).

Koho sa tu snazis presvedcit o com? Stale iba prezentujes svoj nezmyselny nazor pretoze s danou vecou nemas skusenosti. Nie je ti neprijemne sa takto znemoznovat?

Ještě jednou: netykáme si. Jak se řekne slovenky "slušnost" a "vychování"?

Proč je můj názor nesmyslný? Jaké požadavky máte na interface? Abyste mohl dělat jen akce u kterých znáte příkaz, aby nebylo na obrazovce vidět co děláte, a aby program bez školení nešlo ani korektně ukončit?

Pokud jsem to pochopil správně, tak právo posuzovat vi/vim má jen ten, kdo jej používá denně po dobu 5 let a více?

Tvoj nazor je nezmyselny lebo o danej veci nic nevies. To ako keby si prisiel za pretekarom od Ferrari a zacal mu rozpravat aka je Skodovka skvele auto a to jeho Ferrari nestoji za nic lebo to nema poriadny kufor a ze ty sa predsa nemozes mylit lebo si to myslis. A tych gombikov co je na volante a ked neviete ktory co robi lebo to na nom nie je napisane to je ale debilny interface. A naviac to robis na fore kde chodia iba vodici formul.
Fakto to nevidis ako sa strapnujes?

Zkuste se třeba vyjádřit k tomu, co jsem psal. Takhle se jen ztrapňujete.

No, v podstatě bych se pod tohlea si podepsalo dost lidí. V jednodušším programu se vždycky dost pracuje. A to, že Vi(m) bez manuálu dokonce nemáte šanci ani ukončit(!) asi nemůžete popřít. Dost začátečníků si to samo vyzkoušelo. Osobně je tenhle dinosaurus první věcí, kterou vyhazuju z nainstalovaného systému. Kdysi na PP06 a 486SX (když ještě po trojhmatu smrti automaticky nevyskakoval eNTéčkový task manager) jsem si osvojil averzi k věcem, které se nedají ukončit jinak než restartem...

Ano, vidím to stejně..

Vi(m) bez manuálu dokonce nemáte šanci ani ukončit(!)

ja vam nevim, kdyz spustim vim, tak to pise:

type  :q<enter>               to exit

kdyz dam ctl+c

Type  :quit<enter>  to exit Vim

a kdyz dam F1, tak se doctu

Close this window:  Use ":q<enter>

nicmene, myslel jsem, ze schopnost cist (a psat) je docela zasadni prekondici pro pouzivani textoveho editoru

To víš, LOovi není v argumentaci nic svaté, leckdy ani pravda nepřežije konfrontaci s jeho vehemencí. :]

Není to nějaká opačovaná verze? Nejsu slepé jak aptrona (úplně). Taky je možné, že to za ten rok a půl, co mi to naposled vytřelo zrak, konečně trošku zcivilizovali :)

Tohle je tam minimálně od pětky, jestli mě paměť sakra nešálí. :]

Nejspíš ano.

OK, máte bod. Bohužel vi to nepíše.

> Jak jsem několikrát psal, pokud ve vi/vim neznáte konkrétní příkaz, tak danou akci nemůžete použít (a zůstane vám navždy utajená).

Jaky je rozdil mezi moznosti nalezeni nezname funkce v menu a moznosti nalezeni nezname funkce v dokumentaci?

Ja vidim tyto:

- v menu clovek muze hledat jen podle jmena (maximalne muze cist jeste tooltipy), navic musi rucne projit vsechny submenu rucne, protoze v menu se neda vyhledavat.

- v dokumentaci clovek zada vyhledat klicove slovo a snadno najde prislusny prikaz ci klavesovou zkratku.

Samozrejme, pokud ma nekdo panicky strach ze cteni dokumentace, tak je druha varianta pro nej nepristupna.

Jak jsem psal, přerušit editaci dokumentu, otevírat dokumentaci, hledat v ní příkaz (o kterém ani nevím jestli tam je), zapamatovat si ho nebo napsat na papírek.... To je děsivý opruz. A jen proto, že někdo v sedmdesátých letech napsal (tehdy pochopitelně) editor bez menu, který dodnes z neznámého důvodu trčí na každé instalaci unixového OS, a který z nepochopitelných důvodů někteří lidé pořád používají.

Takže si položme otázku jinak: proč by SW neměl mít vizuální nabídku, ze které můžete vybírat akce? Je snad ovládání nějak efektivnější proto, že nevidíte, co děláte? Naopak - je méně efektivní, hůře se učí, nemůžete udělat co neznáte.

> přerušit editaci dokumentu, otevírat dokumentaci, hledat v ní příkaz (o kterém ani nevím jestli tam je),

To je ale prakticky stejne jako kdyz hledam polozku v menu - prerusim editaci dokumentu, otevru menu, hledam v nem polozku (o ktere ani nevim, jestli tam je).

Vyvolani dokumentace je casto stisk jedne klavesove zkratky - podobne jako vyvolani menu. V dokumentaci navic je mozne fulltextove vyhledavat. Proc by melo byt nalezeni nezname funkce v menu jednodussi nez nalezeni nezname funkce v (dobre) dokumentaci?

Možná proto, že menu je součástí aplikace, je logicky tříděné, a může být kontextové.

Jasně, už před sebou vidím jedno z možných kontextových menu ve Vimu:

Replace one character
Replace two characters
...
Replace 25 characters
---------------------
Select one word
Select two words
...
Select 25 words
---------------------
Increment value by 1
Increment value by 2
...
Increment value by 100
---------------------
Decrement value by 1
...
Decrement value by 100
---------------------
Go to the top of the buffer
Go to the second line
...
Go to the 1000th line
Go to the bottom of the buffer
---------------------
Join with the next line
Join with next 2 lines
...
Join with next 10 lines
---------------------
Yank to register a
Yank to register b
Yank to register c
...
Yank to register z
---------------------
Go to the marker a
...
Go to the marker z
---------------------
Insert name of the currently edited file
...

Asi si konečně pořídím monitor s pořádným rozlišením, aby se mi tam z toho menu vešlo co nejvíc. ;-)

Zkuste se podívat, jak řeší problematiku jiné editory. Například nemáte v menu položky "Go to line 1" až "Go to line (počet řádků v souboru)", ale položku Go to line... Po její aktivaci vložíte číslo řádku, a stisknete enter. Klávesová zkratka bývá typicky CTRL+G, jako Go, takže stačí CTRL+G 1234 ENTER. Najdete to v menu, a dá se to jednoduše a efektivně používat z klívesnice. Obdobně v ostatních případech.

Z vašeho příspěvku je jen vidět, že toho o (G)UI víte dost málo.

Tak tak. Ještě tam překáží ten CTRL. Mně stačí 1234g a nemusím si lámat prst nějakými modifikátory. Přeci jen když člověk produkuje velká množství textu, musí si dávat pozor na zátěž prstů.

To je naprosý nesmysl. Programátoři ani admini neprodukují velká množství textu. Velká množství textu produkují sekretářky a písařky, kupodivu v MS Office.

Ale pobavil mě ten argument. Vy sice nemáte IntelliSense, takže místo tečka-p-tab píšete plné ".PropertyValue", a ve výsledku napíšete textu mnoho násobně více, ale hlavně, že ušetříte jeden stisk CTRL, který je důležitý, abyste si neošoupal prsty :)

Já žádné .PropertyValue nepíšu, když už, tak spíš mapM nebo foldl. Mimochodem, prozradím Vám sladké tajemství: Doplňování kódu se nemusí nutně jmenovat IntelliSense™, aby i přesto fungovalo. A už máte ve Visual Studiu taky fuzzy doplňování? Nedal bych bez něj ani ránu. Prefixové doplňování je "soooo 90's", jak by řekli Američané. :]

Aha, vy zřejmě používáte takové ty klasické unixové jazyky typu Perl, kde zdroják vypadá, jako když se někomu zasekl shift. A to pak ještě najdete odvahu psát něco o "soooo 90's"? 90's jsou pro vás v takovém případě sci-fi ;)

Ale k věci. Co si mám představit pod fuzzy doplňováním?

Cože, já a Perl? Ale kdeže. :-) Pod fuzzy doplňováním si představte třeba to, že kdybyste měl dvě properties a jedna by se jmenovala PropertyValue a druhá PropertyType, tak by Vám stačilo zadat .pv<tab> pro PropertyValue a .pt<tab> pro PropertyType. Kdybyste měl třeba .PropertyValue a .PropertyValidator, za chytré fuzzy doplňovaní by se dalo dalo používat takové, kterému by pro jednoznačné určení, že chcete .PropertyValidator, stačilo třeba jen .pvr<tab>. Dlouhé shodné prefixy identifikátorů zvláště v "ukecaných" jazycích typu Java a C# klasickému doplňování IMHO nepřidávají příliš mnoho na použitelnosti. Jistě, jako nápověda je to pěkné, ale pokud vím co chci a jen se nechci upsat, co mi nabídne IntelliSense v takovémhle případě? Napíšu .pr a pak budu lozit šipkama po všech PropertyWhatever?

Nemám tu teď VS 2008, ale domnívám se, že holt musíte lézt šipkama po všech PropertyWhatever (ono jich zřejmě bude méně než 3, takže je to celkem jedno). Fuzzy doplňování by mohlo být fajn. Jenom kdyby vám ve vimu fungovalo nejen na klíčová slova, ale také na vaše vlastní třídy, metody a proměnné, dokázalo rozeznat scope toho co nabízí atd. Když jsem se díval naposledy, tak byla podpora doplňování nesmírně omezená.

Doplňování ve Vimu je plně programovatelné, protože autor editoru neměl ambice řešit všechny existující jazyky. Ovšem každý jazykový režim může sám o sobě využívat doplňovací widget Vimu prakticky k čemukoli (třeba takhle: http://sontek.net/blog_pictures/vim_code_completion.png) a tahat informace o dostupných objektech jazyka prakticky z jakéhokoli zdroje. Podobně je tomu u Emacsu, ten má v základu fixní doplňování abbrev (asi tak trošku na způsob automatických oprav ve Wordu, které se k tomu také dají zneužít) a dabbrev (který po zadání prefixu a stisknutí Meta-/ najde nejlépe odpovídající slovo, které se již nachází souboru), což je asi tak maximum, co se dá dělat zcela obecně bez jazykových režimů. Ale třeba jazykový režim SLIME pro Common Lisp má nabízí právě fuzzy doplňování identifikátorů ze všech načtených knihoven včetně uživatelského kódu. (Teď si nevybavím, jestli do toho přidává i lokální lexikální bindingy, ale to není až takový problém, když pominu možnost přidávání vazebních forem přes defmacro.)

Děkuji, pěkná informace. IntelliType je samozřejmě také rozšiřitelný.
Podpora doplňování ve VS je holt výrazně dále, než ve vimu. Pěkné krátké summary je zde:
http://www.codeproject.com/KB/dotnet/vs2008JSIntellisense.aspx

Předpokládám ale, že Eclipse a podobná prostředí jsou na úrovni VS.

"Podpora doplňování ve VS je holt výrazně dále, než ve vimu."

Ehm, "holt je dál?" Tak mně spíš přijde, že podpora (rozšiřitelného) doplňování je ve Vimu i ve Visual Studiu na přesně téže úrovni, totiž na té, že je - ona buď může být, nebo není, víc možností člověk nevymyslí :-). Jak daleko jsou jednotlivá doplňování, to je otázka jiná. Out-of-the-box bez doplňků bude Visual Studio mít lepší doplňování C#, a Vim zase bude mít lepší doplňování Pythonu, přičemž do obou se dá jako add-on přidat to, co umí ten druhý. Co myslíte tou "úrovní VS?"

Nějak mi není jasné, proč bych se měl zabývat doplňky pro automatické doplňování, zvláště když mluvíme o vývoji aplikace - očekávám hotové nástroje. Faktem je, že vim nenabízí zdaleka ty samé možnosti, jako VS, a to minimálně proto, že IntelliSense není jen doplňování (viz link v minum příspěvku k tématu).

Zapomněl jste na něco, příteli. Anglická abeceda má o podstatně méně písmen, než má Vim příkazů. Takže obdobně v ostatních případech by to nebylo možné, protože klávesové zkratky s Ctrl jsou vesměs už obszené, Alt je nepoužitelný, protože by to kolidovalo s ovládáním hlavního menu, Shift by se použít nedal, protože byste určitě volal po zrušení modality Vimu, takže by byl potřeba k psaní velkých písmen, skvělá klávesa Win by to nevytrhla, nemluvě o tom, že například v Linuxu máme dobrý zvyk definovat si v desktopovém prostředí globální klávesové zkratky a klávesa Win se k tomu velice často používá. Pokud se Vám líbí sekvence klávesových zkratek s Ctrl, použijte Emacs, nic Vám nebrání, uživatelé Vimu si mohli rovněž vybrat Emacs, ale Vim jim připadá vhodnější. Editorů je k dispozici několik desítek, sice jsou některé z nich vhodné spíš pro BFU, ale na tom není nic špatného. Vim je, jaký je a právě proto jej někteří lidé používají. Vědí, jaké má výhody, Vy ne, jak jste sám přiznal. Takže LOL, milý LO.

Odpoviem ti za LO aby sa nemusel namahat.
Ja si myslim ze VI je aj tak prezity lebo ine editory su intuitivnejsie a VI je prezity. To s tymi klavesami jednoznacne znamena ze VI je horsi ak nie uplne najhorsi a najneintuivnejsi editor na svete.
Sice som s VI nikdy nerobil ale si myslim ze to co pouzivam ja je uplne najlepsie a vy ostatny sa musite hrozne mylit ak pouzivate VI.

Díky, přesvědčil jsi mě. Tohle byla poslední kapka. ;-)

Tohle bylo dost ubohé i na váš standard, že?

1) Ne všechny akce GUI musí mít přiřazenou zkratkovou klávesu. Zkratkové klávesy jsou potřeba na ty věci, které se používají často. Co se používá méně často, zvolíte z menu, nebo pomocí Alt+písmeno-z-menu. Navíc jsou tu víceúrovňové zkratky, jistě znáte třeba CTRL+E,F.

Emacs jsem nikdy nepoužíval. Samozřejmě kdybych byl digitálním archeologem, narazil bych na něj. Mám ale za to, že na standardní unixové instalaci je vi, a není tam emacs. To je také asi jediný důvod, proč se má smysl editorem vi vůbec zabývat - je to jediný použitelný editor, který na unixovém systému určitě bude. Když chci změnit IP adresu v konfiguráku, musím prostě umět vi. Jak unixové :(

> Možná proto, že menu je součástí aplikace, je logicky tříděné, a může být kontextové.

(dobra) dokumentace byva take soucasti aplikace (dostupna z aplikace na klavesovou zkratku) a logicky tridena. Navic v ni je typicky videt vic veci najednou - kdyz se podivam do menu, vidim jen jmena polozek, ale uz ne popisky (ty jsou schovane v tooltipech). V dokumentaci uvidim jmena prikazu a rozumne popisky na jedne strance, navic v nich mohu vyhledavat.

Je pravda, ze kontextova dokumentace se vidi malokdy.

Kontextovou dokumentaci mají třeba lepší IDE. Když je kurzor například na můjObjekt.Exe*cute(), tak tisk F1 přejde na dokumentaci metody Execute, samozřejmě příslušející k třídě, které je můjObjekt instancí. Alespoň ve VS to tak funguje.

"V případě non-GUI to je typicky TeX, což je obrovsky mocný nástroj, ale má tak zásadní omezení, že ho nelze nasadit na většinu činností."

Pro každého je ta "většina" jiná množina. Sázíte Ženu a život? :-) Rozumná použitelnost TeXu IMHO končí někde na půl cesty mezi matematickými pracemi a Ženou a život. Kdysi jsem myslel, že je to víc posunuté k tomu prvnímu, ale Hagenův ConTeXt a XeTeX od SILu mě přesvědčily, že TeX zdaleka ještě nenatáhl brka. Záleží asi na tom, co člověk dělá. Dříví na táborkák asi nemá smysl řezat motorovou pilou. :-)

Ten princip je i v jiných programech, InDesign není první na světě (vývojová prostředí to mají už dávno)

Nepříliš překvapivě, první program, který tohle měl, byl Emacs, což není zrovna dedikované vývojové prostředí. Hned pak zřejmě Vim. :-) Ale souhlas, program, který má nabídky, efektivní klávesové zkratky, a ještě tenhle třetí ("příkazový"?) způsob, je takřka dokonalý. (Tím spíš, pokud program podobně jako třeba Emacs po spuštění příkazu tímhle způsobem navíc ještě na okamžik napíše nápovědu typu "You can run the command 'fill-paragraph' with M-q", stejně jako jsou klávesové zkratky indikovány v nabídkách, a člověk si to zapamatuje.)

Někteří zastánci *vi* už dávno znají programy s možnostmi podobnými výše zmíněným vlastnostem InDesginu a někteří z nich je dokonce i umí ocenit (což je skutečně velká poklona - nikdo není tak konzervativní jako programátor).

To je jednoduché, podobné možnosti, jako popisujete, má právě Vim. Alespoň konfigurační balík Cream z něj dělá praticky to, co popisujete - od bohatých nabídek, přes CUA("Windows-like") zkratky (stylu Ctrl+X, Ctrl+V) a modální/jednoklávesové zkratky ("Vi-like") až po příkazový režim. Takže jestli to popisujete věrně, věřím, že uživatel Vimu by se cítil v Indesignu CS3 právěže jako doma.

Já taky nechci do ničeho zabředávat. Opravdu mě to vážně zajímalo. :-) Nuže, myslím, že s takovýmhle záběrem pro Vás je Indesign skutečně asi nejvhnodnější nástroj. Mám k němu taky velký respekt, i když já zrovna potřebuju spíš tu matematiku a sám bych InD neupotřebil, koneckonců zrovna v tomhle oboru nedělám.

K tomu TeXu - je třeba si uvědomit, že i TeX byl vymyšlen za konkrétním účelem a tím nebyla obecná DTP typografie, ale sazba technických dokumentů. To, že ho Knuth vymyslel tak, že tento svůj primární úkol vysoce překračuje a umožňuje toho mnohem více, ještě neznamená, že byl jako obecný DTP nástroj taky zamýšlen. Takže já bych to spíše otočil - TeX nemá zásadní omezení, ale naopak - je koncipován tak otevřeně a neomezeně, že to až svádí pohlížet na něj jako na univerzální DTP nástroj, kterým ve skutečnosti není a nikdy ani neměl ambice se jím stát.

Já jsem taky nijak vašemu příspěvku neoponoval, jen jsem se pokusil o upřesnění. S tím, co píšete, vcelku souhlasím. Pokud jde o tu univezalitu, tak Knuth skutečně NECHTĚL vytvořit univerzální typografický nástroj! To, že ho navrhl tak variabilně, je důsledkem něčeho jiného - totiž vývojového přístupu, raženého kromě Knutha i např. Moorem, jehož základním paradigmatem je "neklást si do cesty zbytečná omezení, která ve skutečnosti ze zadání vůbec nevyplývají". Osobně jsem (nebo spíše pokouším se býti) také vyznavačem tohoto přístupu a fakt, že se moje SW či HW produkty dají použít i k jiným věcem, než pro něž byly původně navrženy, zdaleka neznamená, že mým cílem bylo vytvoření univerzálního produktu. Univerzalita ve světle tohoto přístupu NENÍ záměrem, je jen vedlejším produktem. Což může být pro spoustu lidí dost nepochopitelné ;-)