ESR: Emacs by měl opustit bzr a přejít ke Gitu

Eric S. Raymond se nechal slyšet, že bzr (Bazaar), systém pro správu zdrojových kódů vyvíjený Canonicalem, je mrtvý a Emacs by proto měl přejít k něčemu jinému. Doporučuje Git, a to i ze "sociálních" aspektů.

3.1.2014 12:53 | Luboš Doležel (Doli) | Komunita

Komentáře

[pavlix]

Kéž by k tomu došlo víc projektů. Na druhou stranu vůbec nemám problém s tím, aby nad Gitem vznikaly různé nadstavby. Jediný problém je v tom, že už základní vlastnosti Gitu jsou širší než budou někteří chtít přijmout. Větvená historie s merge commity je asi nejkontroverznější.

[xkucf03]

Nechci teď hodnotit Bazaar, ale představa gitovské monokultury je mi proti srsti…

A tohle je taková definice kruhem:

Sticking to a moribund version-control system will compound and exacerbate the project's difficulty in attracting new talent.

Když se bude všude používat jen Git, tak budou mít nováčci problém s jinými systémy, na které nejsou zvyklí a nikdy je neviděli → proto bychom všude měli používat Git.

[s]

Zase na druhou stranu, myslenka - "nebudu to pouzivat proto, ze to pouzivaji vsichni" je snad jeste ujetejsi Napadlo te treba, ze to, ze vsichni pouzivaji git, nemusi byt jen davova psychoza, ze to muze byt proste tim, ze je git tak dobry? Co myslis?

[xkucf03]

Někdy mi právě přijde, že to davová psychóza je. Už jen v této diskusi několikrát padlo něco ve smyslu:

I would have preferred Mercurial …

I can understand hating git; the UI is pretty nasty …

Agreed, from my experience. Mercurial's UI is better, too.

Naopak výhodou Gitu je, že ho spousta lidí zná – takže pokud už se Gitem někdo prokousal, bude se mu lépe přispívat. Což je celkem relevantní argument, to nepopírám.

Na druhou stranu přílišná uniformita je taky na škodu a přijde mi lepší žít s tím, že existuje více (D)VCS a dá se pracovat se všemi, než očekávat, že všude bude jediný správný verzovací systém. Řešení vidím spíš v abstrakci – pak se nebude stávat to, že někdo investuje obrovské úsilí do vytvoření nadstavby nad nějakým VCS – a ta bude nepoužitelná s jiným VCS, i když většina je stejná a bude se to programovat pořád znova a znova. Např. u relačních databází jsme už před mnoha lety dospěli k tomu, že máme abstraktní vrstvy jako JDBC nebo PDO a pod nimi ovladače pro konkrétní DBMS¹.

_{[1] SŘBD}

[mirec]

Abstrakcia má jednu zásadnú nevýhodu: limituje aj tie najlepšie systémy na možnosti toho najhoršieho. GIT podporuje rôzne šialenosti (priama práca s objektmi ...) ktoré sa v iných VCS nedajú dosiahnuť.

[xkucf03]

To není pravda, abstrakce buď může podporovat maximální možnou funkcionalitu (s tím, že ne každý ji musí podporovat) nebo jen část, ale na ten zbytek použiješ speciální rozšíření. Např. na většinu věcí můžeš použít stejné abtraktní rozhraní, ať je pod tím sqlite nebo PostgreSQL. Případně to může být modulární, můžou být různé úrovně podpory standardu.

U těch verzovacích systémů chceš v IDE např. vidět, které soubory/řádky se změnily (nejsou commitnuté), vypsat si historii, vypsat si u každého řádku souboru, z jaké verze pochází a kdo je autorem, udělat commit vybraných souborů do aktuální větve atd. To je pro všechny systémy společné. A nějaké speciality si můžeš udělat na příkazové řádce bez abstrakce nebo pomocí nějakého rozšíření.

Máš vlastně tři skupiny funkcionality:

• obsažené v abstrakci i VSC – ideální stav
• obsažené jen v abstrakci → implementace vyhodí výjimku nebo budeš mít nějaký mechanismus na signalizaci, která funkcionalita je podporovaná
• obsažené jen ve VSC → použiješ rozšíření/modul nebo komunikuješ s VCS na přímo bez abstrakce

Čím větší je ta první skupina, tím lépe, ale v zásadě jakákoli nenulová množina je plus, protože to umožní znovupoužitelnost, ušetří práci – někdo napíše ovladač pro nový VCS a rázem ho můžou všichni používat skrze svůj software, aniž by museli něco doprogramovávat; nebo někdo napíše novou GUI aplikaci a rázem ji mohou používat uživatelé všech VCS, pro které jsou ovladače (aniž by autor té GUI aplikace musel vůbec tušit, že tyto VCS existují).

[s]

nikdy sem u gitu necitil potrebu pouzivat UI a nikdy sem ani zadne nepouzival. Krev se mi peni, kdyz s nekym neco probiram, on chce commitnout jeden soubor a misto aby napsal git add, git commit, spusti jakesi UI a zacne klikat... Podobnou mam averzi treba i k mc, ale toto tema je trochu offtopic , a to, ze nekdo nema rad git, protoze ma rad mercurial, to imo neni argument.

pro mne teda furt git +1 pro svou rychlost a jednoduchost a taky asi proto, ze s nim umim a lepsi neznam. Zato horsich znam hned nekolik

[xkucf03]

Krev se mi peni, kdyz s nekym neco probiram, on chce commitnout jeden soubor a misto aby napsal git add, git commit, spusti jakesi UI a zacne klikat...

Vtip je v tom, že nemusíš spouštět jakési UI – máš už otevřené IDE (případně editor) a v něm ten konkrétní soubor (soubory), tam jednou dvakrát klikneš nebo zmáčkneš klávesovou zkratku, napíšeš zprávu a odentruješ – je to rychlejší, než se přepínat do konsole, psát příkaz a vybírat znova soubory…

Osobně používám Mercurial, něco (asi většinu) dělám na příkazové řádce a něco v IDE, podle toho, co je v tu chvíli víc po ruce a pohodlnější. Jsem rád za obě možnosti. Ale takový diff v IDE/editoru (podbarvené změněné řádky) je k nenahraditelný.

[Jakub Lucký]

Ale takový diff v IDE/editoru (podbarvené změněné řádky) je k nenahraditelný.

Na tohle je skvělá Idea/PHPStorm/Pycharm...

[xkucf03]

Já to mám v Netbeans

[mess]

Já zase v KDevelop, QtCreatoru, Eclipse ...

[Jakub Lucký]

Ano, takhle se používá SVN na Windows... za poslední měsíce jsem si s tím v práci užil své...

[----]

Další výhoda Gitu je, že je mocnější než mercurial; má lepší branches, má interaktivní rebase, ...

a interface k gitu mi přijde v pohodě (teda ten konzolový, s GUI nemám žádné zkušenosti) - hlavně pro běžné věci je to triviální.

[stativ]

V čem má git lepší branche? Používám obojí, i když preferuju mercurial, a branche mi přijdou nastejno. Jinak interaktivní rebase se v mercurialu jmenuje histedit.

[stativ]

Jen dodám, že tím nevyvracím, že git nemá nějakou funkcionalitu navíc, ale to se dá říct i naopak. Např. u gitu mi schází podpora largefiles, naopak u mercurialu bych uvítal něco jako "git clone --depth" (IIRC se ale vývojáři vyjádřili, že tohle v mercurialu nechtějí) a možnost editoru hunku při commitu jako je u "git add -p".

[pavlix]

u gitu mi schází podpora largefiles

Co si pod tím má laik představit?

[stativ]

Je to něco jako centralizovaný VCS uvnitř decentralizovaného. Snaží se to řešit klasický problém asi všech DVCS, kterým je ukládání velkých binárních souborů, kde moc dobře nefunguje komprese.

V mercurialu lze označit soubor jako largefile. Mercurial pak pro takový soubor funguje jako centralizovaný systém, kde na vybraném serveru jsou všechny revize a na klientovi je jen cache s verzemi, které klient potřebuje (a kterou je možné smazat). Je to dost užitečné pro různé artworky, které se moc často nemění, ale které zaberou spoustu místa.

[pavlix]

Musím ti dát bod za snahu, ale ten tvůj popis je opravdu strašný. Jestli to správně chápu, tak jde o to, že si stáhneš jen mělkou historii (což Git částečně umí), akorát selektivně dle atributu nějakého souboru.

Mně osobně takhle možnost moc užitečná nepřijde a řešil bych to buď pomocí archivu nebo pomocí Git submodule, který bych klonoval jen mělce. Na druhou stranu implementovat takový atribut pro konkrétní soubory by v gitu bylo vcelku triviální, takže v tom nevidím problém, pokud to někdo za užitečné považuje.

Je to dost užitečné pro různé artworky

Nemyslím si. Pokud má být pro ty artworky výhodný Git, tak nejspíš s plnou historií. Pokud pro ně výhodný není, tak se dají distribuovat jako archiv. Není problém v Gitu udržovat buď verzi toho archivu nebo rovnou hash.

Je to dost užitečné pro různé artworky, které se moc často nemění, ale které zaberou spoustu místa.

Asi záleží o jak velké soubory jde a kolikrát za život projektu se změní. Ale pokud už takové soubory mají být v Gitu i kdyby jen na serveru, není důvod, aby zabírali místo ve stejné větvi (ve stejném repozitáři) jako kód. Ve chvíli, kdy se jedná o Git submodule, není problém tato data jako celek klonovat bez historie.

Neříkám, že je v Gitu práce s mělkými kopiemi a se submoduly úplný med, ale spíš bych se soustředil na zlepšování tohoto než přesouvání granularity na jednotlivé soubory. Ale rád si poslechnu i jiný pohled.

[stativ]

Musím ti dát bod za snahu, ale ten tvůj popis je opravdu strašný.

Díky za bod, mě se můj popis docela líbil

Jestli to správně chápu, tak jde o to, že si stáhneš jen mělkou historii (což Git částečně umí), akorát selektivně dle atributu nějakého souboru.

Historie, pokud jde o commity, se stáhne celá, akorát data ne. Dalo by se taky říct, že pro largefiles mercurial verzuje metada, kdežto data jsou zvlášť.

Mně osobně takhle možnost moc užitečná nepřijde a řešil bych to buď pomocí archivu nebo pomocí Git submodule, který bych klonoval jen mělce.

Ten názor ti neberu. Já třeba submoduly v oblibě zrovna nemám a k archivu nemám hezkou historii.

Pokud má být pro ty artworky výhodný Git, tak nejspíš s plnou historií. Pokud pro ně výhodný není, tak se dají distribuovat jako archiv. Není problém v Gitu udržovat buď verzi toho archivu nebo rovnou hash.

Largefiles právě kombinují do jisté míry obojí. Oproti shallow clone nebo separátnímu archivu v logu vidím všechny commity. Zároveň ale nemusím na disku mít i stará data, která nejspíš nikdy potřebovat nebudu. A když už bych je náhodou potřeboval, tak se stáhnou ze serveru (tady je výhoda oproti archivu, protože k nim mám historii).

[pavlix]

Historie, pokud jde o commity, se stáhne celá, akorát data ne.

Já osobně se na Git rád dívám jako na objektovou databázi. Stažení celé historie commitů bez samotných adresářů a souborů je v celku triviální. Takže celá ta legrace bude především o tom, aby nad tím dobře fungovaly nástroje, které v tuto chvíli s takovou situací nepočítají.

Dalo by se taky říct, že pro largefiles mercurial verzuje metada, kdežto data jsou zvlášť.

Git udržuje o souborech jen minimum informací a ty jsou součástí tree objektů, tedy adresářů. Pokud jsou potřeba nějaká další metadata, typicky se ukládají jako obyčejné textové soubory a můžou se vázat i na cesty, na kterých žádný objekt není (.gitignore). Takový nástroj by byl vhodný i pro označení toho, čemu říkáš large files, protože by mohl předvídat i soubory, které zatím nebyly přidány.

Podle mě by nebyl problém ani stahovat si celý strom, pouze vynechávat vybrané či všechny datové soubory. Ale opět se naráží na to, že by bylo potřeba uzpůsobit nástroje na práci s neúplnou informací.

Já třeba submoduly v oblibě zrovna nemám

Tak artwork reálně submodulem je. Starají se o něj často jiní lidé. Lze upravovat do jisté míry samostatně. Podle mě je škoda ho slévat s kódem. Implementace submodulů v Gitu by jistě zasloužila vyšperkovat, ale jejich nepoužití v takových případech podle mě vede k tomu, že se člověk dříve nebo později spálí.

Largefiles právě kombinují do jisté míry obojí.

Tak to ani v nejmenším. Funkce submodulu nelze nahradit tím, že si označím soubor a nestahuju jeho historii.

Oproti shallow clone nebo separátnímu archivu v logu vidím všechny commity.

V případě submodulu si dokonce můžeš vybrat, zda tě zajímá jeho historie samotná nebo v kontextu celého projektu. Navíc mi pak přijde užitečné si pro celý submodul stáhnout jen metadata a k nim aktuální data, očemž už jsem psal výše a člověk by ani nemusel řešit nějaké značkování souborů.

A když už bych je náhodou potřeboval, tak se stáhnou ze serveru (tady je výhoda oproti archivu, protože k nim mám historii).

To by pro submodul s metadaty a aktuálními daty platilo úplně stejně. Já v tom vidím dva rozdílné pohledy na stejný problém, přičemž bych ale stále preferoval ten s granularitou submodulů, nikoliv jednotlivých souborů, ale jinak jsou si velmi podobné a je to prostor, ve kterém by se mohl Git dále zlepšovat.

[xkucf03]

Tak artwork reálně submodulem je. Starají se o něj často jiní lidé.

To je pak podobná situace jako u knihoven – a tam mi přijde lepší necpat cizí binární knihovny do mého úložiště, ale verzování nechat na autorech té knihovny a mít nějaký systém, jak si dotáhnout potřebné závislosti (od distribučního balíčkovacího systému .deb/.rpm přes Maven, Ivy, CPAN, CTAN a další až po vlastní skript, který nakopíruje potřebné knihovny ze sdíleného disku). Cpát tyhle věci do verzovacího systému je mi proti srsti, mám radši minimalistická úložiště, kde je jen to nejcennější, ale je fakt, že Largefiles tuhle moji nechuť trochu snižují.

[Ed]

Pokud chces konkretni pripad:

Git repozitar dat pro Flightgear flight simulator (hlavne modely letadel) ma asi 11GB. Klon trva i na rychle lince mnoho hodin. Pritom drtive vetsine lidi (vcetne tvurcu tech modelu) staci jen aktualni nebo posledni tagovana verze). Ale zase pokud se hleda, proc treba nefunguje autopilot, je dobre mit kompletni historii zmen pro nektere (XML) soubory.

Na submodulech me stve, ze git archive je tise ignoruje.

[pavlix]

To zní jako docela běžný příklad. No je to jak jsem říkal, Git potřebuje v této oblasti vylepšit toolset. Ale nemít tyhle data v submodulu považuju za zločin, i kdyby motivovaný nedostatky gitovských nástrojů.

Pokud jde o git archive, náprava by nemusela být až tak složitá.

[Martin Mareš]

Co třeba git-annex?

[pavlix]

To vypadá zajímavě.

[stativ]

Tak o tom jsem nevěděl. Díky.

[JS1]

Ahh, diky moc, to jsem dlouho hledal, takovy software!

[pavlix]

Mimochodem, zdrojem zajímavých informací je i toto. Jsou tam odkazy na několik dalších projektů, které můžou být pro některý konkrétní účel vhodnější.

[kolcon]

vypada to zajimave, az na jednu vec.

Jestli to spravne chapu, tak mi to ty soubory presune do sveho .git adresare a nahradi je symlinky.

Nejsem si uplne jisty, ze chci mit v adresarich kupu symlinku kamsi, misto dat.

Co se stane, kdyz se rozhodnu, ze git-annex prestanu pouzivat? Jak jednoduse z tech symlinku dostanu zpatky ty soubory?

[xkucf03]

Na to bude stačit krátký skriptík. Horší je, když uvnitř těch souborů (nebo vůči nim) budou nějaké relativní odkazy – pak je dost možné, že software, který s tím pracuje bude brát jako výchozí cestu místo, kam symlink odkazuje, ne to, kde se nachází.

[JS1]

Bohuzel, lepsi system asi neexistuje, aspon dokud filesystemy nepodporuji neco jako "odkaz na vzdalene uloziste". Coz je v podstate ten symlink...

[xkucf03]

To by šlo udělat přes FUSE – některé soubory by byly lokálně a některé by se tahaly až v případě potřeby ze serveru. Pro aplikace by to bylo transparentní.

BTW: proč by to nemohly být pevné odkazy? Nebo mít ty soubory jen v pracovní kopii, ale verzovací systém by věděl, že to nejsou běžné verzované soubory a jak se k nim má chovat.

[pavlix]

ShareBox je postavený nad git annex.

[JS1]

Toho jsem si vedom, ale stejne si myslim, ze (desktopove) aplikace s tim, ze soubor muze byt docasne nedostupny (pro vysokou hodnotu casu - zvlast kdyz se musi treba cekat na lidskeho operatora, aby pripojil disk) obecne prilis nepocitaji.

[JS1]

Idealne bych si predstavoval: Chci si prehrat film, otevru si ho v prehravaci (nebo kliknu na ikonu), a napise mi to:

"Soubor .. (s filmem) je ulozen na offline mediu XYZ. Pokud ho chcete prehrat, pripojte prosim to medium. OK Zrusit"

Jenze na neco takoveho musi byt (IMHO) podpora jak na urovni aplikace, tak na urovni FS. Mozna by to slo udelat i pres ruzne KIO Slave nebo podobne, nevim.

[Vlad]

... a možnost editoru hunku při commitu jako je u "git add -p".

hg record ?

[stativ]

Ten samozřejmě znám a možnost upravit hunk nemá. Ve wiki je na to i feature request.

[David Jaša]

Jeden z původních autorů bzr psal už před rokem, že je to efektivně mrtvá věc, takže se spíš divím, že akutální článek na podobné téma někoho překvapí.

[pavlix]

+1

Dokonce mám dojem, že jsem zaslechl něco o možnosti reimplementovat bzr CLI jako nadstavbu nad gitem.

[xkucf03]

Že by pak Git měl konečně použitelné UI? To by bylo fajn. (ale stejně bych radši emulaci rozhraní Mercurialu)

[pavlix]

Tož používat se to dá, jen je to trochu kostrbaté. Nejsem si jistý, jestli emulace nějakého stávajícího rozhraní je ta nejlepší cesta, ale pokud by nad gitovskými repozitáři umělo pracovat více různých nástrojů, tak by to určitě dobře posloužilo poznání různých přístupů.

[xkucf03]

Jak jsem psal, bylo by to fajn. Ono je to hlavně o tom, že Git je spíš nízkoúrovňová databáze než systém pro správu verzí (který by sám o sobě nějak podporoval workflow při vývoji softwaru).

[pavlix]

Jen pokud ignoruješ jeho vysokoúrovňové příkazy.

[podlesh]

On asi naráží na to, že nad těmito vysokoúrovňovými příkazy je ještě celá další velká úroveň: workflow. Většina rozšířených VCS workflow neřeší, git dokonce myslím záměrně a je to jeden z důvodů popularity, protože různé projekty používají velmi odlišná workflow.

[pavlix]

Psal o nízkoúrovňové databázi, což jsou podle mě typicky nízkoúrovňové příkazy pro manipulaci s objekty v databázi. Vysokoúrovňové příkazy už tvoří systém na správu verzí, ač nevynucuje konkrétní workflow.

[David Jaša]

přímo v článku:

Could bzr have a second life as another UI for the Git file format, becoming part of the Git world rather than competing with it? Sure, I guess. Several people, including myself, have suggested this in the past. It would however still require a fair amount of work - bzr-git is unfinished. If it's just the UI you're after then it is probably easier to simply build a bzr-like Git UI from scratch, directly on top of something like libgit2 or Dulwich.

[pavlix]

Díky.

[Radim Kolář]

Jeste se na bzr trochu dela.

Bzr pouzivam a vyhovuje mi, s rychlosti nemam pri praktickem nasazeni problem. Pokud pouzivam git tak jen proto abych mohl posilat veci pres github.

Jediny co mi u bzr chybi je cherry-pick

[OldFrog {Ondra Nemecek}]

Chápu to dobře, že hlavní problém bzr je špatný výkon u opravdu rozsáhlých projektů?

[OldFrog {Ondra Nemecek}]

Protože jinak podle mě na verzovacím systému zas tolik nezáleží a současné distrubuované systému se používají všechny podobně a není problém se naučit pár nových příkazů, ne? Osobně bych systém neměnil, pokud neklade opravdové technologické překážky (např. tu limitující rychlost).

Možná je to ale takových projektů jako je emacs jinak (nemám zkušenost).

[GeoRW]

Skor obava toho, ze vyvoj Bazaaru stagnuje a kedze Git vyhrava suboj o developerov a projekty, tak je lepsie prejst nanho, aby prip. mohol Emacs motivovat vyvojarov prispievat aj do neho Inak Git je rychly a ma niektore navyse featury, ale pre 99.9% projektov (vratane Emacsu) ten rozdiel nehra ziadnu ulohu. BTW, Emacs uz aj tak skoro nikto nepuziva

[pavlix]

Popravdě řečeno se při balíčkaření starám snad jen o jeden projekt v bzr a než se jím zabývat, tak radši nad stromem pustím quilt a spravuju si patche s ním. Takže tenhle argument vidím jako velmi silný.

[stativ]

+1

[JS1]

BTW, Emacs uz aj tak skoro nikto nepuziva

Nejsem si tak jisty, rekl bych, ze v posledni dobe Emacs zaziva urcity navrat, asi diky Lispovym (a dalsim) jazykum, a take diky zlepseni funkcionality, treba integraci systemu balicku, lepsi praci s fonty, atd.

[pavlix]

Emacs už má balíčkovací systém jako ostatní OS?

[Martix.]

+1 ELPA, Emacs už jen chybí ten kernel...

[stativ]

Však čekají na GNU Hurd.

[Bedňa]

Nečakajú, však sa doň dá nabútovať z Linuxu a je to celkom sranda, hral som sa tým hodinku. Len tie skratky mi pripadajú na hlavu

[Conscript89]

No, myslim ze horsi nez VCS je pro novacka v projektu samotny elisp :)

[JS1]

Co vy o tom muzete vedet..

Je to prave naopak. Tim, ze se Elisp pouziva jak na konfiguraci, tak na rozsirovani, je ta "learning curve" daleko nizsi, nez u modernich IDE.

Vim to z vlastni zkusenosti. Par rozsirujicich funkci jsem si do Emacsu uz napsal, ale studovat nejake zbesile Javove API pro rozsirovani treba Eclipse se mi opravdu nechce..

Takze prave proto, ze je Emacs tak *snadne* rozsirit, ho ma kazdy nastaveny po svem. Uvazujte o tom.

"Those who don't understand Lisp are condemned to reinvent it, poorly."

(Jinak Emacs umi barevne odlisovani diffu samozrejme take, dokonce bych rekl, ze to je vec starsi nez ona IDE.)

[xkucf03]

ale studovat nejake zbesile Javove API pro rozsirovani treba Eclipse se mi opravdu nechce.

Jakkoli může být API Eclipse zběsilé (neznám), výhoda je v tom, že máš k dispozici online dokumentaci (JavaDoc) tříd a metod a napovídání v IDE – víš jaké metody která třída nabízí, jakých typů mají být argumenty, jakých typů jsou návratové hodnoty a v důsledku toho zase víš, jaké metody na těch objektech můžeš volat – díky tomu se dá dobře učit za chodu.

[JS1]

Elisp a Emacs je take vyborne zdokumentovany.. Nejenom ze ma Emacs dokumentaci primo v sobe, dokonce je mozne primo skocit na zdrojak prislusne funkce. A napovidani to umi taky.

[Ivan]

Mensi plugin jsem napsal jak pro Emacs tak i pro Eclipse. U Emacsu jsem mel problem vybavit si po 10ti letech zaklady Lispu, ale nakonec jsem to dal. U Eclipse jsem mel problem, ze se vsechno hrozne rychle vyviji a vetsina navodu na internetu je neaktualni. Javadoc v tomhle pripade moc nepomuze, je potreba vedet jak presne poskladat ruzne tridy dohromady a hlavne co napsat do ruznych zbesilych XML formatu. Navic u Eclipse musite vyvijet plugin v jedne instanci a ladit a debugovat ve druhe. Celkove bych rekl, ze vyvoj pluginu pro Eclipse ma mnohem plossi learning curve. Uz jenom zprovozneni prostredi pro vyvoj pluginu mu zabralo cely den.

[JS1]

Celkove bych rekl, ze vyvoj pluginu pro Eclipse ma mnohem plossi learning curve.

Asi jsi chtel napsat strmejsi, jestli jsem spravne pochopil ten komentar.

[David Jaša]

Až nedávno jsem pochopil, že termit "učící křivka" má dva významy a zrovna v angličtině se používá častěji (výhradně?) ten druhý.

[JS1]

Vida, to mas pravdu. Me vyhovuje ten vyznam, ktery odpovida analogii vystupu na horu. Strmejsi -> clovek se vic nadre.

[Ivan]

Aha. Me utkvel v pameti obrazek z nejakyho XKCD komixu kde byl na horizontalni ose cas(resp. usili) a na vertikalni ose uzitek. Svym postem jsem chtel rict ze u Eclipse prekvapive dlouho trva nez storite neco uzitecneho (v mym pripade to byl patch pro plugin zalozeny na XTEXTu).

[JS1]

No hlavne, ze si rozumime. Ja jsem zadny Eclipse plugin nedelal, ale prave hlavne ty XML konfiguraky me desi. Je to asi vec, ktera mi nejvic vadi na Javovem ekosystemu - oni delaji DSL a nechteji si to proste priznat.

[xkucf03]

Co je na tom XML tak děsivého? Copak tolik záleží na tom, jestli ty závorky kolem dat jsou špičaté, kulaté nebo složené? Nevím, jak u Eclipse, ale obvykle ke XML dostaneš schéma, takže víš, co tam máš psát.

Je fakt, že někdy je to XML jen formálně a ve skutečnosti je v něm zapsaný procedurální program, ve kterém voláš konstruktory tříd, metody, předáváš parametry… to mi přijde trochu zbytečné, ale není to chyba XML, ale toho, kdo ho takhle použil. Radši mám, když konfigurace jsou neživá data (ne program), ale opačný přístup může mít taky něco do sebe. Např. logování v Javě můžeš nakonfigurovat přes properties soubor (klíč=hodnota), což znamená nastudovat si dokumentaci, zjistit, jaké klíče tam můžou být, jak se zapisují zanořené struktury a pak to vyzkoušíš, jestli jsi to pochopil správně a loguje to, jak má. Nebo můžeš místo properties souboru poskytnout název třídy – tzn. napíšeš jednoduchý program, který inicializuje logovací subsystém – píšeš to v jazyce, který znáš, IDE ti napovídá názvy metod a datové typy a během psaní se ti to pod rukama kompiluje, takže máš hned kontrolu chyb. To mi přijde celkem dobré. Jako druhou dobrou možnost vidím XML s dobře udělaným schématem – tam máš taky online nápovědu a okamžitou kontrolu.

[Martin Mareš]

Co je na tom XML tak děsivého?

Že je to věc na první pohled jednoduchá, ale ve skutečnosti nebývale komplikovaná a obskurní. Zkoušel jste si někdy pečlivě přečíst specifikaci?

[xkucf03]

Celou ne, ale občas si v tom čtu, když si potřebuji něco ujasnit – přijde mi to stejně srozumitelné jako běžné specifikace

[Martin Mareš]

Především mi přijde zásadní otázka, proč pro tak jednoduchý cíl (zápis stromů) zvolit něco takhle složitého. XML neumí oproti lispovským S-expressions nic zajímavého navíc, a přesto je jeho specifikace (i implementace) o několik řádů složitější.

[JS1]

Ja bych byl optimista, dneska uz hodne lidi preferuje JSON, treba se nakonec k tem s-expressions nejak dokonverguje..

[JS1]

Narozdil od Martina si nemyslim, ze zrovna syntaxe je ten nejvetsi problem (i kdyz zrovna v pripade XML to je dost hrozne).

Problem je prave v te myslence, ze konfigurace (chces-li to tak nazvat, neni to uplne vhodne) maji byt data. U uzivatelskeho konfiguraku se to da pochopit (ale i tam to u vetsich systemu narazi), kvuli bezpecnosti.

Ale u programu samotneho, treba u statickych dat, jak ma vypadat layout? Zazivam tohle ted na Androidu, a je to hruza. Potiz je totiz v tom, ze obcas je potreba neco vytvaret dynamicky (napr. ja chci udelat paletu tlacitek). Takze se podpore pro tu konfiguraci primo v jazyce stejne nevyhnes. To co vznikne bude hybrid - kus bude v XML, druhy kus bude v Jave.

Coz ma mnoho nepraktickych dusledku. Napr. chci neco statickeho predelat na dynamicke, nebo jenom malinko "zdynamicnit". Dusledek je, ze ted mam definici rozkouskovanou na dvou mistech, v ruznych zapisech. (Podobnym problemem trpi Javascriptove aplikace, kdy se cast HTML/CSS vytvari dynamicky..)

Ve skutecnosti by ale stacil jen jeden jazyk, dostatecne silny na to, aby se v nem daly ty DSL vytvaret. V nem by se pak dalo zapsat oboji, v unifikovane syntaxi, a bylo by to krasne prehledne.

Tohle neni nova myslenka - uz ji objevil Lisp, Forth, do jiste miry i Haskell.. (o tom poslednim ti asi rekne vic Martin, ale myslim, ze to ukazuje, ze to jde realizovat i s typovou kontrolou, pokud je to tvoje uchylka.. )

Proste, Javiste by si IMHO meli priznat, ze domenove specifickym jazykum se v programovani nelze vyhnout. Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.

[xkucf03]

Zní to dobře, ale obávám se, že to není pro každého. Pro běžného uživatele je to příliš mocný nástroj a hrozí, že si to rozvrtá. Taky to dost odhaluje vnitřní implementaci – to může být problém, když ji chceš změnit → staré konfiguráky (ve kterých může být zapsané cokoli) pak přestanou fungovat (nebo tě to omezuje v možnostech měnit vnitřní uspořádání programu). Neživá data (ať už XML nebo něco jiného) můžeš taky snadno vygenerovat, převést na něco jiného, napsat k nim GUI editor nebo aspoň zobrazovač – protože je to uzavřená množina kombinací, které lze vytvořit. Jakmile je to jednou program, tak ta složitost je neomezená a musíš se k tomu už vždy chovat jako k programu.

To co vznikne bude hybrid - kus bude v XML, druhy kus bude v Jave.

Zrovna na takovém programu pracuji – výchozí konfiguraci¹ mám v Javě² a uživatel si ji může překrýt svojí konfigurací v XML – tam má celkem omezené možnosti, ale zase je to jednoduché a snadno pochopitelné – a kdyby mu to nestačilo, tak si napíše vlastní třídu v Javě a odkáže se na ní z té konfigurace.

Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.

Ono není potřeba rozšiřovat Javu jako takovou – součástí Javy je JSR 223: Scripting for the Java Platform – konfigurace může být třeba v Groovy a z něj se budou volat javovské metody, které nějak zkonfigurují tu aplikaci. Myslím, že nástroje celkem jsou – otázka je, jestli by se uživateli chtělo „programovat konfiguraci“ – tady mi právě přijde, že pro něj bude stravitelnější napsat nějaké to XML, kde mu editor poradí, jaké elementy/atributy tam má psát. Jak by to bylo v případě skriptu? Dejme tomu, že zná ten jazyk – ale určitě nezná metody/funkce/konstrukce, které ten konfigurační DSL tvoří – to by si musel nastudovat v nějaké dokumentaci.

V případě toho mého XML si otevřeš konfigurák v Emacsu a začneš psát – a editor ti na základě Relax NG schématu říká, jestli to píšeš dobře nebo ne. Dole hned vidíš (nXML Valid) nebo naopak konkrétní chybu. V případě nějakého skriptu/DSL by Emacs (nebo jiný editor) tuhle informaci vzal kde?

Něco jiného by bylo, kdyby konfigurákem byla Javovská třída – tu by si uživatel otevřel v IDE a všechny tyhle informace, nápovědy a kontroly by tam měl. Jenže to by jednak uživatelé remcali, že pro pohodlnou konfiguraci potřebují IDE a nestačí jim jejich oblíbený XML editor, a jednak by to byl asi až příliš mocný nástroj v rukou uživatele (viz výše).

_{[1] ono je to na hraně mezi konfigurací a součástí samotného programu
[2] tzn. typová kontrola a kontrola syntaxe zadarmo, používání společných konstant (nemám tam nějaké magické textové řetězce, které by na sebe musely pasovat a musel se mezi nimi udržovat soulad)}

[JS1]

Samozrejme, ten argument s konfiguraci je trochu mimo, protoze uz na zacatku jasne rikam, ze nemluvim o konfiguraci, ale o vecech, ktere se zapisuji v XML a pritom nejsou soucasti konfigurace (jako treba layouty na Androidu, Ant build "skripty", ruzne DI..).

To programovani konfigurace ma hlavni vyhodu - muzes si vybrat vlastni parametrizaci. O tom to cele je.

Ale zapomen na to, vidim, ze jsi ztraceny pripad..

[xkucf03]

treba layouty

Zrovna tohle je dobrý příklad. Když to budou data, tak může existovat nějaký vizuální návrhář, kde si člověk to GUI nakliká. Dokonce to ani nemusí dělat programátor, ale někdo přes GUI – a programátor to už „jen“ oživí.

Jenže když to bude program, tak žádná taková editace není možná.

Totéž platí pro uživatelskou konfiguraci – dejme tomu, že uživatel si chce nastavit nové databázové připojení. V případě XML k tomu může existovat přívětivý editor, kde si všechno nakliká, aniž by přišel do styku se zdrojákem. Na druhou stranu v případě programu si může udělat konfiguraci třeba takovou, že každý den v týdnu uvidí jiná databázová spojení. Každé má svoje.

Rozumné mi přijde oba přístupy kombinovat – co jde udělat deklarativně, to udělat tak, a co nejde, pro to mít nějaký dodatečný skript/program, který to doladí.

Ale zapomen na to, vidim, ze jsi ztraceny pripad..

To bych nerad ale chci dát uživatelům nějakou úroveň pohodlí a možností. Dejme tomu, že pro konfiguraci použiji nějaké DSL nebo prostě něco jiného než XML. Jak se mám dostat na stejnou úroveň přívětivosti, kterou mi teď nabízí XML a základní¹ instalace Emacsu? Tzn. editor napovídá, kontroluje syntaxi a hlásí chyby. Uživatel nemusí vědět, že ta struktura je zrovna takováhle:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration xmlns="…">

    <database>
        <name>…</name>
        <url>…</url>
        <userName>…</userName>
        <password>…</password>
    </database>

    <database>
        …
    </database>

</configuration>

Prostě otevře konfigurák v editoru a všechno potřebné se dozví tam. Rád se přiučím, jak podobného výsledku dosáhnout pomocí něčeho jiného než XML.

_{[1] v Debianu/Ubuntu, ale to bude asi všude stejné}

[JS1]

Ale tobe porad unika ta pointa - nic z toho co rikas se navzajem nevylucuje s tim mit to jako DSL v ramci skutecneho programovaciho jazyka.

Dokonce i Eclipse me pri vyvoji na Androidu prekvapil, kdyz ve skutecnosti ten layout zobrazuje i z toho, co se definuje v Jave. To uz mohli interpretovat tu Javu rovnou.. Proste si to tim XML formatem jenom zbytecne komplikuji.

[xkucf03]

nic z toho co rikas se navzajem nevylucuje s tim mit to jako DSL v ramci skutecneho programovaciho jazyka

Jedna věc je, jestli se to teoreticky nevylučuje a druhá věc: jsou na to běžně v praxi dostupné nástroje?

• XML: běžný editor + schéma → uživatel ví, co tam může psát a jestli tam nemá chyby
• DSL: jak dosáhnout srovnatelného výsledku??

Přijde mi to, jako bys mi radil psát programy pro mainframy – sice to může být teoreticky lepší, ale většina lidí doma mainframe nemá a takový program jim bude na nic. Ale XML lidi znají. I když na něj třeba občas nadávají, snad každý ví, jaké závorky a uvozovky tam má psát. Běžné editory, které ty lidi už mají, jim umí zvýraznit syntaxi, načít schéma, napovídat, validovat. V distribucích jsou nástroje jako xpath, xmllint nebo xsltproc.

Chápu tu myšlenku, co tu padla, že uživatel se naučí psát konfiguraci a pak už mu zbývá jen málo a už si píše rozšíření, plynule přechází od konfigurování k programování. Ano, líbí se mi to… Na druhou stranu: programy se píší v mnoha různých jazycích – copak má uživatel umět jazyk každého programu, který používá? V tomhle je XML docela dobrý jednotící prvek – píšu konfiguraci pořád stejně a můžu abstrahovat od toho, v jakém jazyce je ten který program napsaný – jednou to může být C++ jednou Java jindy Perl… pro základní konfiguraci a použití programu ani nemusím vědět, v jakém jazyce je. Stejně tak můžu používat pořád ten samý editor pro úpravy konfiguráků.

Možná je cesta psát programy jako hromadu modulů/funkcí, které se poslepují pomocí Guile, a tím dostanou výslednou formu programu, a současně se v Guile bude psát i konfigurace… ale stále tomu v praxi chybí některé nástroje a stále platí některé moje připomínky: deklarativní (data) vs. procedurální (program) a z toho vyplývající výhody/nevýhody.

To uz mohli interpretovat tu Javu rovnou.

Interpretovat kód programu není tak složité, horší je opačný postup: mám výsledek, ten nějak upravím (ať už vizuálně klikáním nebo jinak) a pak z toho chci dostat opět zdrojový kód – a ne ledajaký kód, ale ten původní, ve kterém budou provedené jen minimální nutné změny. Když ten DSL bude dostatečně omezený a deklarativní, tak by to jít mělo – ale když bude plnohodnotným programovacím jazykem a bude procedurálním, tak to je asi úkol pro umělou inteligenci.

[JS1]

Jedna věc je, jestli se to teoreticky nevylučuje a druhá věc: jsou na to běžně v praxi dostupné nástroje?

Kdyby navrhari nebyli idioti a netravili cas implementaci XML rozhrani, mohli by ty nastroje davno mit. Mozna se pletu, ale komercni Lispova prostredi nebo Smalltalk takove nastroje maji take, adaptovane pro jejich konkretni jazyk.

Ale XML lidi znají. I když na něj třeba občas nadávají, snad každý ví, jaké závorky a uvozovky tam má psát. Běžné editory, které ty lidi už mají, jim umí zvýraznit syntaxi, načít schéma, napovídat, validovat.

Tohle je myslim jadro toho problemu (a odpovida to na Martinovu neprimou otazku, proc tolik lidi vidi v XML kladivo). Ty hodnotis veci prilis povrchne, podle syntaxe. Jenze o syntaxi to vubec neni! Podstatna je semantika.

V tomhle je XML docela dobrý jednotící prvek – píšu konfiguraci pořád stejně a můžu abstrahovat od toho, v jakém jazyce je ten který program napsaný – jednou to může být C++ jednou Java jindy Perl… pro základní konfiguraci a použití programu ani nemusím vědět, v jakém jazyce je. Stejně tak můžu používat pořád ten samý editor pro úpravy konfiguráků.

A to je prave ten omyl, ktery souvisi s tim povrchnim pohledem. Ve skutecnosti to nemuzes takto delat, protoze je podstatna semantika toho XML, nikoli syntax - jak pise Ivan. Jestli se to zapisuje jako XML nebo sexpy nebo Java, je naprosto nepodstatne. A prave proto je idealni pouzit stejnou syntaxi, jako ma programovaci jazyk, ktery pouzivas (a proto je dulezite, aby ten jazyk umel snadno definovat a kombinovat jak deklarativni, tak proceduralni zapisy).

deklarativní (data) vs. procedurální (program) a z toho vyplývající výhody/nevýhody.

Ale ja nejsem proti deklarativnimu zapisu! Jen jsem proti tomu omezit se jen na deklarativni zapis, a to je trochu rozdil. Protoze mnohokrat je moznost proceduralniho generovani deklarativniho zapisu velice uzitecna.

Interpretovat kód programu není tak složité, horší je opačný postup: mám výsledek, ten nějak upravím (ať už vizuálně klikáním nebo jinak) a pak z toho chci dostat opět zdrojový kód – a ne ledajaký kód, ale ten původní, ve kterém budou provedené jen minimální nutné změny. Když ten DSL bude dostatečně omezený a deklarativní, tak by to jít mělo – ale když bude plnohodnotným programovacím jazykem a bude procedurálním, tak to je asi úkol pro umělou inteligenci.

Vzdyt to delat nemusis. GUI generator proste vygeneruje deklarativni zapis. Pokud ho zmenis tak, ze pouzijes nejake proceduralni procesy, rekne ti to proste - sorry, nemuzu to znovu zobrazit, nerozumim tomu. Porad ti to ale dava vic moznosti nez to zakazat uplne.

Prikladem muze byt treba editor nastaveni v Emacsu. Ten generuje ciste deklarativni sexpy. Pokud je zmenis tak, ze budou proceduralni, holt to nebude schopen zpetne zpracovat. Coz ti nemusi vadit - predpoklada se, ze kdyz uz to menis rucne, tak vis co delas.

[xkucf03]

Ty hodnotis veci prilis povrchne, podle syntaxe. Jenze o syntaxi to vubec neni! Podstatna je semantika.

Zrovna o té syntaxi a sémantice jsem už jednou něco psal: Jak (ne)používat XML – při popisovaném použití je to XML opravdu na nic, bereš si z něj jen syntaxi a o sémantice nevíš nic, tu si musíš vycucat z prstu nebo nastudovat někde bokem. Ale když to XML použiješ správně, tak tam máš jak syntaxi (vychází ze samotného XML), tak sémantiku (vychází ze schématu, které jsi k tomu formátu dodal).

Jestli se to zapisuje jako XML nebo sexpy nebo Java, je naprosto nepodstatne. A prave proto je idealni pouzit stejnou syntaxi, jako ma programovaci jazyk, ktery pouzivas

Může být. Netrvám na konkrétní syntaxi plné ostrých závorek a uvozovek, klidně se ten strom objektů může zapisovat jinak a klidně stejnou syntaxí jako zbytek programu, s tím fakt nemám problém a asi by se mi to i líbilo. Ale potřebuji k tomu odpovídající nástroje – takové, které poskytnou srovnatelné pohodlí jako u toho XML. Tzn. např. textový editor, který si načte javovské třídy (nebo jiné definice) a bude schopný uživateli radit, jaké položky tam může vyplnit, poskytovat k nim online dokumentaci a hlásit mu případné chyby (jak v syntaxi tak sémantice).

Ještě k té abstrakci a nezávislosti na jazyku: dejme tomu, že jsem admin a na serveru mám aplikace psané ve třech různých jazycích – asi nebude moc praktické mít tři různé editory nebo si instalovat tři různé moduly do editoru, pro ty různé syntaxe (což je způsobené tím, že autor aplikace chtěl mít konfiguraci ve stejném jazyce jako program). Naopak by se mi líbilo, kdyby všechny konfiguráky byly v jedné syntaxi (ať už jakékoli, nemusí to být XML), já měl jen jeden editor a vždy si pouze načetl schéma pro danou sémantiku.

Ty se na to díváš z pohledu programátora a chceš používat jeden jazyk – ale když se na to podíváš z pohledu uživatele/administrátora, tak ten by taky rád používat stejný jazyk pro konfiguraci aplikací (naprogramovaných v různých jazycích). To je neřešitelný rozpor – buď by bylo potřeba psát všechny aplikace v jednom jazyce (kterém?) nebo se prostě jedna strana (programátor nebo uživatel) musí přizpůsobit.

Vzdyt to delat nemusis. GUI generator proste vygeneruje deklarativni zapis. Pokud ho zmenis tak, ze pouzijes nejake proceduralni procesy, rekne ti to proste - sorry, nemuzu to znovu zobrazit, nerozumim tomu. Porad ti to ale dava vic moznosti nez to zakazat uplne.

Tam se ale snadno dostaneš do pasti – lehce si vygeneruješ spoustu kódu, dokud je deklarativní, tak se to dá ukočírovat¹, ale jakmile to jednou překlopíš do procedurální roviny, tak už není cesty zpět a máš hromadu kódu, se kterou se už musíš nějak vypořádat sám.

Líbí se mi, jak tohle řeší Netbeans – GUI si tam můžeš naklikat, jeho deklarativní popis je uložený v nějakém XML a z něj se generuje procedurální tvar v Javě – a některé jeho části jsou needitovatelné – právě proto, aby bylo možné je kdykoli přegenerovat z toho deklarativního popisu. Ty pak píšeš vnitřky těch vygenerovaných metod (např. obsluha událostí tlačítek), kde máš typovou kontrolu a všechno pohodlí tvého programovacího jazyka, ale nemůžeš editovat signaturu té metody, protože pak by nepasovala na ten zbytek (můžeš ji leda smazat). Ty needitovatelné části kódu ti ale nebrání v tom, aby sis tam dopsat inicializační metodu, která už procedurálně doladí to GUI, třeba tam dynamicky vygeneruje tlačítka do deklarativně připraveného panelu nebo naplní texty a popisy.

Jak jsem psal, netrvám na konkrétní syntaxi a klidně bych i uvítal, kdyby ta syntaxe deklarativních a procedurálních částí byla podobná, vycházela ze stejného jazyka, ale zatím jsem nic takového (s vhodným ekosystémem nástrojů kolem toho) prostě neviděl.

Prikladem muze byt treba editor nastaveni v Emacsu. Ten generuje ciste deklarativni sexpy. Pokud je zmenis tak, ze budou proceduralni, holt to nebude schopen zpetne zpracovat. Coz ti nemusi vadit - predpoklada se, ze kdyz uz to menis rucne, tak vis co delas.

Ale to, že uživatel je schopný psát procedurálně, ještě neznamená, že to tak chce dělat vždycky – já např. taky umím dělat procedurálně GUI ve Swingu, ale pokud to jde, tak si ho radši naklikám (tzn. leze z toho nějaké deklarativní XML a z něj se teprve generuje procedurální kód) a procedurálně napíšu jen to nezbytně nutné – a ty deklarativní části můžu kdykoli editovat v GUI editoru.

_{[1] slušný nástroj, který ti umožnil snadno něco naklikat, ti to umožní i snadno smazat nebo nějak hromadně změnit}

[kralyk z abclinuxu]

Zatímco syntaxi XML zná prakticky každý, XML schémata, XSLT a tyhle věci už zná podstatně méně lidí...

[pavlix]

A z těch co znají, má z nich ještě podstatně méně radost.

[xkucf03]

A kolik lidí ovládá Lisp nebo jiný programovací jazyk?

Navíc nemusíš umět psát schémata nebo XSLT na to, aby sis pustil xsltproc a podíval se třeba na výsledné XHTML v prohlížeči, nebo aby sis do editoru načetl XSD a věděl, že máš XML dokument správně, nebo kde je v něm chyba.

[kralyk z abclinuxu]

A kolik lidí ovládá Lisp nebo jiný programovací jazyk?

Když už bych si musel vybrat mezi naučit se základy Lispu, nebo naučit se XML schémata, bral bych osobně to první. No ale máme i rozšířenější jazyky, např. JS+JSON, kde je velmi snadné psát jak deklarativní, tak ale i procedurální kód (používá Grunt), dále třeba Lua (používá premake), dál taky lidi často píšou build v pythonu (třeba botan, boost,...). Taky se používají různé DSL, např. CMake má imho docela pěkný a velmi snadno zvládnutelný DSL.

Navíc nemusíš umět psát schémata nebo XSLT na to, aby sis pustil xsltproc a podíval se třeba na výsledné XHTML v prohlížeči, nebo aby sis do editoru načetl XSD a věděl, že máš XML dokument správně, nebo kde je v něm chyba.

Vůbec nevim co je xsltproc, neznám XSLT a naučit se ho by byla v zásadě stejná práce, jako naučit se některé z výše jmenovaných řešení.

[xkucf03]

No ale máme i rozšířenější jazyky, např. JS+JSON, kde je velmi snadné psát jak deklarativní, tak ale i procedurální kód (používá Grunt), dále třeba Lua (používá premake), dál taky lidi často píšou build v pythonu (třeba botan, boost,...). Taky se používají různé DSL, např. CMake má imho docela pěkný a velmi snadno zvládnutelný DSL.

1) Ano, máme mnoho různých jazyků, ale který z nich vybrat? Nakonec se dostaneš k tomu rozporu popsanému v #131 – programátor by chtěl používat jeden jazyk pro programování i konfiguraci vs. uživatel/administrátor by chtěl používat stejnou syntaxi pro konfiguráky programů psaných v různých jazycích.

2) Kde jsou ty nástroje? Konkrétní SW, který by se dal použít teď hned v praxi – ne nějaké teoretické spekulace o tom, co by všechno bylo možné.

Chci, aby si uživatel otevřel můj konfigurák ve svém oblíbeném editoru (např. Emacs) a ten mu kontroloval validitu, hlásil chyby a napovídal možné konfigurační položky – aby nemusel lovit tu sémantiku v nějakých tutoriálech na webu. Aby to byla nějaká známá syntaxe, ne nějaká miliontá první obskurní „jednoduchá“ syntaxe, kde sice stačí napsat méně písmenek, ale uživatel bude znova a znova dumat nad tím, jestli mezi klíčem a hodnotou má být = nebo :, jestli na koncích řádků musí být středníky, a jak se proboha zapisují seznamy.

JS+JSON

JavaScript by možná použít šel, zná ho spousta lidí od webu… a taky se pro procedurální konfiguraci/skriptování někdy používá (resp. používá se ECMAScript). Ale JSON je zabitý tím, že neumí ani ty pitomé komentáře, a i v té jednoduchosti je takový polovičatý – např. nutnost psát názvy klíčů do uvozovek – to už rovnou můžu psát XML atributy název="hodnota".

neznám XSLT a naučit se ho by byla v zásadě stejná práce, jako naučit se některé z výše jmenovaných řešení.

Vtip je v tom, že XSLT se ani moc učit nemusíš. Transformace jde navrhnout tak, že XSL z velké části odráží strukturu výsledného dokumentu (třeba XHTML nebo nějaký XML formát, který uživatel zná a chce ho transformací získat) a sem tam v ní jsou nějaké IFy a cykly… Je to poměrně intuitivní a můžeš to bát jako jednoduchou šablonu – příklad: generuje se XHTML výstup a v něm jsou nečíslované seznamy, ty bys ale radši tabulky, tak otevřeš tu šablonu a předěláš to na tabulky – jediné, co k tomu potřebuješ znát, jsou základy HTML. A to díky tomu, že ta šablona kopíruje strukturu a syntaxi výsledného dokumentu, kterému rozumíš. Případně to může být XSLT, které generuje prostý text, pak je to ještě jednodušší.

Kdyby to bylo třeba v Lispu nebo Pythonu, tak možná budeš umět přepsat <ul> na <ol>¹, ale budeš umět předělat seznam na tabulku? Zjistit, jak přidat další úroveň elementů nebo třeba atributy… to bude o dost složitější než v tom XSLT.

_{[1] pokud se tam nepoužije nějaká abstrakce, která by před tebou skryla řetězce "ol" a "ul"}

[kralyk z abclinuxu]

Ano, máme mnoho různých jazyků, ale který z nich vybrat?

Zejména podle okolností - jaký nástroj na jakou platformu chci podporovat...

Kde jsou ty nástroje? Konkrétní SW, který by se dal použít teď hned v praxi – ne nějaké teoretické spekulace o tom, co by všechno bylo možné.

Snažil jsem se u každého uvést konkrétní nástroj.

JSON má v absenci komentářů určitě nevýhodu (proto si např. sublime komentáře do JSONu neoficiálně přidal, otázka je, jestli to je dobře), ale imho to vyváží snadnost té integrace s JS (resp. ECMAScript).

Vtip je v tom, že XSLT se ani moc učit nemusíš. Transformace jde navrhnout tak, že XSL z velké části odráží strukturu výsledného dokumentu (třeba XHTML nebo nějaký XML formát, který uživatel zná a chce ho transformací získat) a sem tam v ní jsou nějaké IFy a cykly…

Úplně stejný argument platí pro ty ostatní technologie - prakticky všechny z nich se člověk snadno naučí, pokud už je nezná, navíc u nich je imho lepší šance, že budou užitečné i jinde.

Kdyby to bylo třeba v Lispu nebo Pythonu, tak možná budeš umět přepsat <ul> na <ol>¹, ale budeš umět předělat seznam na tabulku? Zjistit, jak přidat další úroveň elementů nebo třeba atributy… to bude o dost složitější než v tom XSLT.

Nebude, protože python podporuje XML (nevim jak Lisp, ale počítám, že taky). Onehdná jsem přesně něco takového potřeboval udělat - přečíst jedno XML, udělat v nějaký změny dat a roztřídit do množiny jiných XML podle určitých podmínek... V pythonu to bylo celkem triviální a nemusel jsem se učit další jazyk+toolset.

Navíc to zdrojové XML bylo potřeba načíst z něčeho obskurního (nějakej vlastní formát jednoho softwaru, kterej si kdosi v jedný firmě ubastlil). V pythonu to bylo celkem triviální (pár řádek), v XSLT by něco takovýho nebylo možný, musel bys stejně použít nějakej jinej jazyk/nástroj a k němu XSLT, a náhle jsme opět u toho samého problému jako na začátku diskuse: XML se v tý chvíli stává pátým kolem u vozu.

[kralyk z abclinuxu]

JSON má v absenci komentářů určitě nevýhodu

Tady by ještě chtělo dodat, že komentáře v XML sice jsou, ale jsou dost debilně řešený (7 znaků na komentář - wtf? Nefunguje nesting, v komentu nesmí být '--').

[xkucf03]

V céčku taky nemůžeš zanořit komentáře – tohle se ti nepřeloží:

/**
 * komentář /** omg */
 */

A v komentáři nemůžeš mít */.

Na jednu stranu lidi nadávají, že psát parser dá moc práce a na druhou by chtěli mít možnost zapisovat kdejaké obskurnosti. Tohle nejde dohromady a je potřeba si vybrat nějakou úroveň jednoduchosti/složitosti.

Spíš by ti mohlo chybět, že XML nemá jednořádkové komentáře, ale to by zase znamenalo vyhradit pro komentáře nějaký znak (např. #), který by se pak ale zase nesměl vyskytovat v textovém obsahu a musel by se nějak escapovat – tzn. zase další složitost pro parser a opruz pro uživatele. Tady je rozdíl oproti programovacím jazykům – v nich totiž nepíšeš libovolný obsah, ale píšeš klíčová slova i identifikátory (libovolný obsah píšeš leda do uvozovek), a tak ti nemusí vadit, že nějaký znak je vyhrazený pro komentáře a nemůžeš ho použít v klíčových slovech nebo identifikátorech.

[kralyk z abclinuxu]

A v komentáři nemůžeš mít */.

Protože tím se ukončuje komentář, takže je logické, že to v komentáři být nemůže. Zatímco v XML by '--' v komentářích klidně být mohlo, nevidím důvod proč ne (vzhledem k tomu, že komentář je ukončen sekvencí '-->').

Jinak v céčku můžeš zanořené komentáře udělat pomocí preprocesoru (#if 0), ale není to zrovna čísté.

Spíš by ti mohlo chybět, že XML nemá jednořádkové komentáře, ale to by zase znamenalo vyhradit pro komentáře nějaký znak (např. #), který by se pak ale zase nesměl vyskytovat v textovém obsahu a musel by se nějak escapovat

Takhle to má YAML, s tím, že # uvozuje komentář kdekoli kromě stringu. Imho docela dobré.

[xkucf03]

kdekoli kromě stringu. Imho docela dobré.

To ano, ale v XML máš ten string kdekoli (kromě názvů elementů/atributů a pár dalších míst)

[xkucf03]

BTW: The Art of Unix Programming:

XML is a very simple syntax resembling HTML — angle-bracketed tags and ampersand-led literal sequences. It is about as simple as a plain-text markup can be and yet express recursively nested data structures. XML is just a low-level syntax; it requires a document type definition (such as XHTML) and associated application logic to give it semantics.

Among the hardest things to get right in designing any text file format are issues of quoting, whitespace and other low-level syntax details. Custom file formats often suffer from slightly broken syntax that doesn't quite match other similar formats. Using a standard format such as XML, which is verifiable and parsed by a standard library, eliminates most of these issues.

[xkucf03]

P.S. Ještě k těm layoutům a GUI: v Netbeans si třeba naklikám nějaký panel, hned vidím, jak jsou vedle sebe tlačítka, popisky, textová pole… což prostě při psaní kódu nevidím – a při tvorbě GUI mi to přijde celkem důležité. Ale hlavní okno aplikace vytvářím ručně v kódu, do něj přidávám ten panel. Jiný panel mám zase ručně a přidávám do něj komponenty dynamicky. A jiný je zase naklikaný, podle toho, jak co je lepší. Dokonce můžu nějaký panel naklikat (tzn. základ je deklarativní) a v inicializační metodě ho doladím, něco přidám, změním texty, hodnoty atd.

[Ivan]

staré konfiguráky (ve kterých může být zapsané cokoli) pak přestanou fungovat (nebo tě to omezuje v možnostech měnit vnitřní uspořádání programu).

A to je presne problem na ktery jsem narazil. XML je pry self-documenting format, takze se nikdo nezabyva nejakou semantikou XML elementu. Nova verze Eclipse vychazi cca 1x za rok a kazda ma trosku jine formaty XML konfiguraku. Navod pro vytvoreni deployment descriptoru pluginu pro Juno uz nefunguje na Kepleru. Resp. to XML je porad "validni" akorat to zjevne nestaci a je potreba jeste neco pripsat aby se vsechny JARy spravne zabalily.

Problem pro me neni ani tak XML format jako takovy. Vadi mi, ze je az prilis snadne ho zmenit a diff nad XSD schematy neni zrovna efektivni reseni.

[kralyk z abclinuxu]

Naprostý souhlas, XML je imho na build systém naprosto nevhodné.

Vzhledem k tomu, že je k dispozici celá paleta dobře známých a snadno použitelných skriptovacích jazyků, tak opravdu nevidím jediný důvod použít XML - není vhodný ani návrhem ani syntaxí.

[Martin Mareš]

Narozdil od Martina si nemyslim, ze zrovna syntaxe je ten nejvetsi problem

Mně to nepřijde jako největší problém, ale jako největší hrůza

Největší problém je samozřejmě, že XML je pro většinu lidí tím velkým kladivem, které když uchopí, cokoliv jim připadá jako hřebík ;)

[JS1]

Nemyslim, ze to je pro vetsinu lidi kladivo - ale proste takova je Javova kultura, tak to delaji.

Ale ja bych mel problem i kdyby Java pouzivala misto mnoha XML (napriklad u tech layoutu) s-vyrazy (jako data). Radu veci lze totiz krasne programove parametrizovat, tak proc se s tim zbytecne psat? Navic to ten jazyk i zjednodusi - ty "jen datove" reprezentace maji casto ruzne ad hoc parametrizace, jako dedicnost apod., ktere by takto zcela odpadly.

[xkucf03]

A brání ti něco to psát čistě procedurálně? Vždyť ten deklarativní konfigurák se přece někde načte, vzniknou z něj objekty a ty se někam dál předávají. Copak nejde tuhle část přeskočit a vytvořit si rovnou ty objekty a pokračovat až od tohoto bodu dál?

[JS1]

Ano, brani mi v tom hloupa syntaxe Javy, ktera neumoznuje vytvaret vlastni DSL. Jeste neco?

[xkucf03]

Můžeš si napsat pomocné metody/funkce nebo si navrhnout nějaké fluent interface – sice to není jazyk, máš tam mezi tím tečky a závorky, ale výsledek je podobný.

Pokud to pořád nestačí, tak můžeš sáhnout po JSR 223 a tu konfiguraci napsat v nějakém jiném jazyce (případně si dokonce navrhnout jazyk vlastní).

[JS1]

Ano, muzu treba pouzit Clojure a napsat to v nem. Ale to tu "learning curve" nezlepsi, jenom prida dalsi vrstvu problemu. Proste rict "muzes pouzit jiny jazyk, da se to na to napasovat" neni omluva pro spatny design.

[kralyk z abclinuxu]

Proste, Javiste by si IMHO meli priznat, ze domenove specifickym jazykum se v programovani nelze vyhnout. Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.

"Java is a DSL to transform big XML documents into long exception stack traces." — Scott Bellware

[kralyk z abclinuxu]

Tak u IDE typu Eclipse (QtC,...) mají pluginy jinou úlohu.

Tomu, co ty popisuješ, je imho podobný například Sublime se svými pluginy/skripty v pythonu...

[xkucf03]

Nebo jEdit, který má jak „makra“ (jednoduché skripty), tak „plug-iny“ (složitější kompilované moduly).

[JS1]

Nevim, co myslis tou jinou ulohou..

Sublime neznam, ale v podstate mi to pripada jako o hodne chudsi Emacs, i filozofii.

Pokud je rozsirovaci jazyk jiny nez ten, v kterem se delaji jednoduche veci, tak to znamena znacny schod na te "learning curve". A o tom to je - nekdo kdo si dnes konfiguruje Emacs mozna zitra napise plugin, protoze to proste prijde samo, jako prirozena vec. U IDE se mu mozna do studia toho API nebude chtit. Proste Emacs svoje vnitrnosti zamerne odkryva pri te konfiguraci, jako pozvanku ho modifikovat; IDE delaji opak.

[kralyk z abclinuxu]

Nevim, co myslis tou jinou ulohou..

U těch zmíňovaných IDE se nepočítá s tím, že by si každý psal plugin, spíš je to výjimečná záležitost. Píšeš, že ostatní IDE neodkrývají vnitřnosti, jako kdyby to bylo špatně. Není to to samé, co umí Emacs, nemá to tu bezbřehou flexibilitu ale to neznamená, že to je nutně špatně (osobně mi to naopak vyhovuje víc - opravdu nevím, proč bych se měl hrabat ve střevech IDE).

Proste Emacs svoje vnitrnosti zamerne odkryva pri te konfiguraci, jako pozvanku ho modifikovat

Zrovna ten Sublime nebo jiné editory dělají to samé.

[JS1]

U těch zmíňovaných IDE se nepočítá s tím, že by si každý psal plugin, spíš je to výjimečná záležitost.

Mne to prijde prave jako skoda. Jinak na tohle tema existuje klasicky clanek.

A taky tento. Zvlast se mi libi citat:

Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

Osobne si myslim, ze myslenka, ze by pocitacove programy mely mit dve tvare, jednu primitivni GUI pro normalni lidi a druhou slozitou pro "ty prave programatory", co chteji delat "velke veci", je scestna (ale bohuzel to ma sve komercni duvody). Mel by proste existovat plynuly prechod.

[Conscript89]

No vidis, a me nedela problem udelat zakladni operace VCS a lisp (asi protoze jsem se ucil Haskell) mi nejak porad nejde. Chci tim rict ze naucit se jazyk je narocnejsi, nez se naucit par prikazu a co znamenaji (bez hlubsich znalosti).

[JS1]

Vzdyt na zakladni konfiguraci Emacsu se nemusis ucit Elisp.. Na zacatku to muzes brat proste jako syntax, pozdeji pridat pochopeni, ze se tak zapisuji operatory, atd. Je to tak pozvolne, ze uz to snad ani pozvolneji udelat nejde.

[Lol Phirae]

U emacsu si to vůbec neumím představit; bzr má naprosto příšerný výkon i u projektů o dva řády menších.

[xkucf03]

BTW: velice podnětná diskuse, doporučuji přečíst.

[Pepe]

umel by tu nekdo shrnout hlavni prednosti i nedostatky pro bzr, git, hg a darcs? dekuju!

[Jakub Lucký]

Dva různé názory

A něco o Darcs

[mimi.vx]

ten článek o Darcs má pěkný závěr ..

Where git rocks:

Git's performance rocks

Git is very fast. Nuff said.

If you need to create a really huge repo, just use git.

The only haskell thing that works good is xmonad. I used it for years and still very happy with it. 
The only haskell things that works fast are qsort and shootout tests.
The other haskell soft is full of shit and I can't understand why.

Gits' branches rock

The same. If you really need to use branches, use git.

Git vs CVS vs SVN vs Mercurial vs Bazaar

And don't think what CVS, SVN, mercurial or bazaar is better than git. It's not truth, these version control systems are much worse

[pavlix]

Používám Git denně, takže asi nemá smysl řešit první odkaz.

Druhý odkaz mi dává smysl. Ale popravdě řečeno snad všechno, co se v tom článku píše, lze řešit čistě na klientské straně (uživatelský repozitář s pracovním stromem) a z velké části se jedná o UI. Tady bych docela preferoval ponechat si Git jako low-level backend a pokud to workflow daného projektu umožňuje, vybrat si frontend dle vlastních preferencí.

Třetí odkaz a vyznačené pozdější úpravy naznačují, že se Git od jeho napsání zlepšil a stále se zlepšuje. V částech, které vyzdvihují darcs nacházím především poznámky ohledně UI a různých operací, což je technicky řešitelné nad Gitovským objektovým úložištěm a tím pádem zcela jistě i se vzdálenými Gitovskými repozitáři. Mimo to tam vidím jasně napsáno, že pokud chci používat větve, mám použít Git.

A popravdě řečeno, na údržbu změn v software větve používat chci. A chci je používat rychle a jednoduše. Git to umožňuje, Mercurial pokud jsem správně pochopil též a Darcs pokud jsem správně pochopil, nikoliv. Bazaar je mrtvý.

Znamená to, že pro mě v open source světě existují dva verzovací systémy. Franta pokud vím používá a preferuje Mercurial, stejně jako mnozí jiní.

Pokud dobře chápu, rozdíl mezi Git a Hg začíná už v identifikaci uložených dat, kde se mi Git zdá funkčně podstatně jednodušší, což beru jako výhodu. Gitovská implementace větví jakožto jednoduchých pointerů na stav projektu s historií mi připadá nepřekonatelná, ale to už Mercurial dohnal. Bezpečnost Gitovských operací pokud jde o existující commity je něco, čeho bych se vzdával dost těžko.

Když tohle všechno sečtu dohromady, ano, občas se kvůli gitovskému CLI koušu do rtu, občas by se mi hodil nějaký nástroj, který v Gitu není, občas si ho třeba i dodělám nebo nějak poskládám pomocí jiných nástrojů, ale nic z toho nevidím jako důvod přejít na Hg.

Pokud by mě to hodně štvalo, napíšu si nad Gitem vlastní nadstavbu, která bude odpovídat mému stylu práce. K tomu už jen zbývá dodat, že mezi projekty, které mě zajímají má Git majoritu,

Tím neříkám, že je Git všespásný, ale pokud jde o jiné VCS, tak mě zajímají jen z pohledu takových případů užití, kde Git nějakým způsobem selhává. Ve většině takových případů bych dal přednost jeho nadstavbě či doplňku.

Jediné, kde bych skutečně rád použil jiný základ je údržba změn jednotlivých souborů. Typicky by to bylo hlídání celého /etc a podobné úlohy, kde bych dal přednost tomu, že bych mohl od začátku trackovat všechny soubory včetně nově vzniklých, ale kdykoli zavádět výjimky a především pracovat s historií nezávisle na tom, které změny přišly ve stejném období.

[Jakub Lucký]

Z toho, co jsem o Darcs přečetl mi přišlo nejzajímavější to nelineární chápání commitů... Viz video v odkaze 3

[pavlix]

Video už jsem viděl, a přišlo mi značně pomýlené. Denně pracuju se závislostmi, které nejsou detekovatelné ze strany VCS.

[Radek Miček]

+1

Hezké by bylo, kdyby VCS rozuměly významu programů a patche obsahovaly například popis provedených refaktoringů. Takové patche by šlo použít i napříč různymi jazyky.

[OldFrog {Ondra Nemecek}]

No, mě se líbí fossil http://www.fossil-scm.org/

Nevím, jak by si poradil s emacsem a je to minorita, nicméně má hezké vlastnosti:

• repositář je sqlite databáze
• fossil spočívá v jediné dobře portovatelné binárce
• zabudovaný webserver, bugtracking systém, wiki
• údajně vysoký výkon a afektivita (nemohu porovnat), vývoj od r. 2007 - dodnes aktivní

[xkucf03]

+1 Fossil má něco do sebe. A v Monotone jsou taky některé zajímavé koncepty.

[Michal Vyskočil]

No, mě se líbí fossil http://www.fossil-scm.org/

Nevím, jak by si poradil s emacsem a je to minorita, nicméně má hezké vlastnosti:

• repositář je sqlite databáze
• údajně vysoký výkon a afektivita (nemohu porovnat), vývoj od r. 2007 - dodnes aktivní

Vysoký výkon s sqlite databází? Někde v dokumentaci ke gitu je schovaný Linusův email na toto téma.

[OldFrog {Ondra Nemecek}]

Co to je za argument? Sqlite přeci nemusí být úzké hrdlo.

Výkon by šel otestovat mirací nějakého projektu z git do fossilu (což nějak lze).

[Kareves]

Existuje skript nazvaný fossil2git, který slouží k opačné věci - zrcadlí z fossilu do gitu. V praxi ho používají vývojáři jazyka TCL, který zrcadlí své repozitáře z fossilu na github.

[OldFrog {Ondra Nemecek}]

Díky za tip, to se může hodit, protože tohle: http://www.fossil-scm.org/index.html/doc/tip/www/inout.wiki funguje - pokud tomu dobře rozumím - pouze jednorázově.

[dustin]

Umí nějaké IDE do gitu commitovat (tedy přidávat do indexu) jen chunky diffů v jednotlivých souborech, tj. necommitovat celé soubory? Je to velice užitečná vlastnost třeba pro commit refaktoringu názvu třídy, když soubory volající třídu (tedy změna) obsahují i jiné změny, které však patří do jiného commitu. Jasně, že by šlo commitovat hned po tom refaktoringu, ale změny si vždy chvíli sedají a dolaďují, než se to commitne.

IntelliJ Idea to myslím zatím neumí.

Obecně rozpad složitější změny do více commitů, aby každý obsahoval jen sobě odpovídající změny a výsledek byl kompilovatelný, je docela složité. V CLI i v mně známých IDEch. Platí to i třeba pro vývoj jádra, kde se na obsah commitů kouká ještě daleko důsledněji, než při uzavřeném proprietárním vývoji.

[dustin]

Jde mi o implementaci git add -i a pak rozpad na patche a chunky.

[xhaakon]

Eclipse EGit toto zvládá. Lze si vedle sebe graficky porovnat soubor ve workspace s jeho podobou v git indexu a libovolně mezi nimi přesouvat chunky změn i ručně editovat. Nakonec commitnout pouze to co je v indexu přes view Git Staging.

http://luksza.org/2011/egit-iteractive-adding/

[dustin]

Paráda, to je přesně ono, díky moc. Teď už jen přesvědčit JetBrains, aby se inspirovali

[Michal Kubeček]

O IDE nevím, ale rozhraní git gui mi připadá dostatečně praktické na to, abych IDE neřešil.

[xkucf03]

Přijde mi to jako chybný postup – ne nadarmo jsou v mnoha týmech pravidla, že by se měl commitovat jen kód, který jde zkompilovat a který prošel testy – což u nějaké ručně vybrané podmnožiny změněných řádků zaručené nemáš.

[pavlix]

Mně to přijde jako zcela správný postup a záruka za správnost je stejná jako u jakýchkoliv jiných úprav, tedy žádná. Před odesláním sady změn je tak jako tak nutné všechny změny otestovat. To se v CLI dělá triviálně.

git rebase -i master --exec 'make && make check'

V mnohých projektech je naopak zakázáno commitovat nesouvisející změny, který si člověk někdy jen tak narychlo splácá, aby něco vyzkoušel a pak je rozloží na nějaké funkční celky, které jsou vhodné k review.

[xkucf03]

Já ale neříkám, že by se měly dohromady commitovat nesovisející věci. Správný postup je podle mého tento:

1. přejmenuji třídu nebo udělám jiný refaktoring
2. udělám clean & build a ideálně pustím testy
3. commit
4. dělám další změny

Případně pokud mám nějakou rozdělanou práci a přijde urgentní požadavek na přejmenování/refaktoring

1. odložím rozdělanou práci (MQ v Mercurialu, staging area v Gitu nebo použití jiné pracovní kopie…)
2. přejmenuji třídu nebo udělám jiný refaktoring
3. udělám clean & build a ideálně pustím testy
4. commit
5. vrátím se k původní práci

Je dobré ten projekt držet v nějakém konzistentním stavu jako celek a nevytrhávat ty změny z kontextu. Protože když to děláš, tak si musíš dávat práci s ruční kontrolou a nesmíš na nic zapomenout, nic nepřehlídnout – zatímco v opačném případě ti velký kus téhle práce ušetří kompilátor a testy.

[dustin]

Správný postup to je teoreticky, ale v praxi po tom refaktoringu ještě řešíš, zda je to provedené správně, zda se s tím dá pracovat dále, zda to nemělo být ještě trochu jinak, Těch commitů by bylo několikanásobně více, z nichž by velká část byla rovnou předělaná na něco jiného. Běžně měním názvy tříd několikrát (triviální úkon), než je dle finální funcionality správně.

Jasně že to můžeš nakonec interaktivně rebasovat a "duplicitní" commity sloučit, ale strávíš s tím spoustu času, navíc ani tohle není silná stránka IDE.

Stačil by mi alespoň staging po chuncích, ani by si to nemuselo pamatovat refaktorovací changeset (i když to by bylo daleko lepší).

[pavlix]

Z praktických zkušeností jsem rád za to, že Git umožňuje změny narychlo naprasit, testnout, jestli to vůbec funguje, a následně změny kousek po kousku rozložit na tebou popsaný ideální patchset. Jestliže to některý systém nepodporuje a člověk to musí řešit ručně, jen těžko to budu považovat za výhodu.

zatímco v opačném případě ti velký kus téhle práce ušetří kompilátor a testy.

Vzhledem k tomu, že mnou popsaný workflow stojí a padá na úspěšné kompilaci a automatizovaných testech, je tato poznámka značně redundantní.

[xkucf03]

Jestliže to některý systém nepodporuje a člověk to musí řešit ručně, jen těžko to budu považovat za výhodu.

Některé systémy to podporují a dokonce i lépe než Git, ale když o to nestojíš, tvoje škoda :-P

[pavlix]

Pak je škoda, že se o takových vlastnostech takových systémů v diskuzi nepsalo. Moc rád bych se o něčem takovém něco dozvěděl, ale zatím nebylo od koho. V praxi bych ovšem uvítal, kdyby nástroj pracoval s gitovským formátem dat, což ovšem není zase takový problém.

[Martin Mareš]

Běžně se mi stává, že při práci na nových kusech zdrojáku narážím na drobné chyby na jiných místech (často třeba jen překlepy v komentářích). Rovnou je opravím, ale testovat a commitovat je chci až časem.

[kralyk z abclinuxu]

Případně pokud mám nějakou rozdělanou práci a přijde urgentní požadavek na přejmenování/refaktoring

1. odložím rozdělanou práci (MQ v Mercurialu, staging area v Gitu nebo použití jiné pracovní kopie…)

Jestli správně rozumím tomu, o co v příkladu jde, tak staging area by nepomohl, spíš stash a/nebo branch...

[dustin]

Záleží podle situace. Pokud je projekt velký, testů hodně a "make check" trvá 10 minut, k tomu vyprodukuješ 10 commitů za hodinu (z nichž polovina je "pridani/oprava komentare", moc se toho za den nenapíšeš. Mimochodem typický příklad, když po někom převezmeš kód, který se ti moc nelíbí.

Samozřejmě třeba u jádra nic jiného nezbývá a sláva bohu za to

[pavlix]

Záleží podle situace. Pokud je projekt velký, testů hodně a "make check" trvá 10 minut, k tomu vyprodukuješ 10 commitů za hodinu (z nichž polovina je "pridani/oprava komentare", moc se toho za den nenapíšeš.

Právě naopak. Při popsaném workflow lze celou sérii testovat třeba i v samostatném adresáři nebo na samostatném stroji a tím pádem snížit časové dopady prakticky na nulu.

[dustin]

?? commit má být co nejmenší množina změn, která spolu souvisí, aby jej šlo snadno revertnout, prozkoumat, atd. Popis commitu má vyjadřovat, co commit obsahuje. Samozřejmě by měl kód po něm fungovat, aby šel použít třeba bisect. Ne vždy je správná funkčnost splnitelná, ale minimálně zkompilovat by to mělo jít vždy.

Velké commity jsou spíše vyjímečné, když se nevyplatí ( = nechce) to rozpadávat na malé - právě třeba kvůli nedostačující podpoře v IDE. Tedy přesně to, na co jsem se ptal.

Kontroly nad commity provádíme až při pushnutí skupiny commitů na server, kdy integrační server (teamcity) kontroluje více commitů najednou. Kdyby měl kontrolovat každý commit odděleně, nestíhal by, kontrola trvá docela dlouho. Ale samozřejmě je také možnost dělat kontroly lokálně, ale nám se osvědčilo centrální řešení, vývojářské stroje nejsou tak výkonné, aby vše stíhaly najednou.

[xkucf03]

V zásadě nic, s čím bych nesouhlasil, ale jak to souvisí s komentářem, na který reaguješ? Četl jsi #45?

[frdrx]

No blik...