idea suckless je fajn , programy by mali byt optimalizovane ale komu sa chce xy krat rekompilovat jeden program navyse ak je urceny pre jedno promile pouzivatelov.. je rok 2013 ti kodrei by sa mohli radsej zaujimat ako spravit nieco uzitocne na projektoch ktore su zive, potrebne pre celu linuxovu komunitu a maju buducnost, ako napr. vyvoj btrfs namiesto vytvarania novych a nepouzitelnych(sta.li).
Přesně tak. Když se zákazník rozhodne od firmy něco koupit, jde buďto za distributorem, který komunikuje s obchodníkem, nebo přímo za obchodníkem (pro ty, co negómó gúgl translate, obchod == market). Obchodník pak zaeviduje požadavek a hlásí managementu, že by byl schopný to a to prodat za tolik a tolik. Management pak schválí rozpočet, timeplan, přiřazení lidí,... a sestavený tým komunikuje s obchodníkem to, co se bude dělat a jak to bude vypadat.
Ve většině případů programátor ví, pro kterou firmu dělá, jenom pokud náhodou dostane nějaký dokument přímo od zákazníka, kterýmu obchodník není štond rozumět. Jinak prostě píše pro marketing podle jeho zadání a pod dohledem managementu. Takže od marketingu je zadání udělat z opice papouška se dvěma kloakama a třema očima, management na to dá tři týdny času a kvůli úsporám smí mít papoušek jenom jedno křídlo...
Proto nepoužívám komenrční software - většinou je nepoužitelný.
Ono než totiž zadání dorazí k programátorovi, přijde na firmu objednávka, kterou zpracuje marketing. Tam je třeba 20 lidí, každý chce mít zásluhu na projektu, tak si přidá svůj zlepšovák, zákazníkovi předloží krásnou nabídku plnou nesmyslů a programátor se diví, co je to za chvostoviny. Však všichno známe nen ilustrovaný příklad s houpačkou.
U open source stačí vybrat to, co se blíží mojí představě a když potřebuju nějakou změnu, prostě to udělám a nekafrá do toho nějaký markeťák z jiné reality, že místo exportu do dalšío formátu dat, "který momentálně použije tak 0,5% zákazníků" radši přidáme v menu shortcut pro výběr obrázku na pozadí desktopu, protože je to cool (a naše aplikace ne práci s textem to ještě neumí).
Požadavky na vývoj ve slušné firmě nezadává marketing. Marketing provádí propagaci a sbírá podněty. Směřování produktu zpravidla určuje nějaká pracovní skupina, ve které je vstup z marketingu jen jedním z mnoha. A problém "na tenhle patník se musím vymočit", resp. "tenhle nesmysl si prosadím abych si cosi kompenzoval", je selháním managementu. Přijde to daleko rozšířenější ve světě open source.
Aha. Takže ve světě open source si uživatel vybere třeba Gimp, a budete si nocích v kódu zrychlovat štětce, učit rozhraní i efekty grafickou akceleraci a psát chybějící content aware nástroje. Jo, takhle přesně vypadá sen uživatele... když trpí nočními můrami :)
Laeli, ty neznáš procesy ve firmách?
1. Každý zaměstnanec má zákazníka, který platí za jeho práci. I programátor.
2. Programátorův zákazník je šéf týmu, který mu přidělí task na projektu.
3. Šéf týmu dostane zadání, co se má vytvořit. Od jeho zákazníka.
4. Zákazník vývojovýho oddělení je marketing. Ten hledá díry na trhu, vyvíjí opičárny, nabízí je zákazníkům firmy, dělá FMEA a další opičárny...
5. Vývoj musí proběhnout tak, aby byl zákazník vývojovýho oddělení spokojený. Takže se dělá to, co si marketing odůvodní. Ne to, co programátor považuje za smysluplný. Defakto pokud nejde o subdodávku a není potřeba např. definovat API, tak je vývoj až za velkým marketingovým firewallem :(
6. Programátor může maximálně poslat na marketing vlastní zlepšovák a nechat je posoudit, jestli to má smysl. Úspěšnost je stejná, jako při vymáhání odškodnýho za nějakou lumpárnu u českýho soudu.
Takže asi tak...
Delal jsem v mnoha firmach, ale v zadne nebylo marketingove oddeleni "zakaznikem" vyvojoveho oddeleni, ve smyslu ze by mu zadavalo praci.
Pokud nekdo do vyvoje mluvil, bud to bylo obchodni oddeleni (coz je dobre, protoze ti maji primy styk se zakaznikem), nebo to byl primo zakaznik (ktery jednal s nekterymi lidmy z vyvojoveho tymu rovnou, nebo v nejhorsich pripadech to byl majitel/reditel nebo obecne nejaky vyssi manager, ktery nepochopil, ze si najima drahe chytre lidi proto, aby svou chytrost pouzivali, a prosazoval vicemene irelevantni zmeny typu: barevne schema musi byt modre!, musime pouzivat c++!, vsechna tlacitka musi byt vlevo nahore!, atd.
Ale NIKDY, NIKDY jsem nezazil ze by marketing nejak definoval co se ma delat.
To by me cece zajimalo, na zaklade kterych podnetu ste tam u vas vyrobili tu zhuverilost win8+. Pripadne ktery zakaznik pozadoval implementaci metra do serveru ...
BTW: Uz ste se naucili do vlastniho systemu nainstalovat vlastni .NET srajdu? To je vazne zuzo, ty vase klikaci postupy ... ktery nefungujou vubec nikde a vubec nikomu.
BTW2: Dik za potvrzeni, ze M$ slusna firma neni.
Ta "zhůvěřilost" Win8+ je určená primárně pro dotekové displaye, ale bez problému se dá používat i s myší. Osobně nevidím problém mít ve Start Menu vystavené ikony aplikací, s možností jedním klikem přejít na plný seznam aplikací. Na rozdíl od malého Start Menu to využívá celou obrazovku a dá se to používat i dotykem. Pokud se vám to nelíbí, můžete si nainstalovat klasické Start Menu.
Já na svůj systém umím .NET Framework nainstalovat triviálně klikacím postupem, a samozřejmě to jde udělat triviálně z command line. Pokud to neumíte, chyba bude zřejmě na vašem přijímači.
Jiste ... a proto na netu vsichni resi, ze to nainstalovat nejde ...ze .. a proto je na webu M$ dism /online /enable-feature /featurename:NetFx3 /all /source:d:\sources\sxs /LimitAccess (respektive tam je neco jineho, co nefunguje, toto aspon obcas funguje)
Takze nemel picoviny. Ten vas uzasnej klikaci postup ... po 20ti minutach kolotani ... nahlasi, ze doslo k nezname chybe a nepovedo se ... proste lol.
Mysi se to pouzivat neda, protoze vazne nehodlam trefovat 1x1px v rozich obrazovky ... vime? Oni totiz existuji uzivatele, kteri ke sve praci potrebujou vic nez jeden monitor, vime? A rozhodne nebude nikdo kupovat do kancelari smatlaci monasy ... to at si M$ strci doprdele. nikdo nehodla celej den cumet do upatlanyho motinoru a machat rukama ...
Ještě se mi nestalo, že by .NET Framework nešel nainstalovat (a to ho potřebuji na každém stroji). Pokud by se mi to stalo, na prvním místě bych si přečetl logy.
Na co potřebujete strefovat do 1x1px rohů obrazovky? Abyste zobrazil Start Menu, pro které máte na klávesnici klávesu? Nebo na zobrazení Charm menu, které je na Win+C? Ve Win 8.1 je navíc podpora více monitorů vylepšená.
Ovládání dotykem samozřejmě můžete použít i v kanceláři. Některé věci se vám dělají lépe z klávesnice a jiné myší; dotek je prostě možnost navíc, která se někdy velmi hodí. Například na spouštění aplikací, zoomování a scrollování je to rychlejší a pohodlnější. Na psaní zdrojáku se "kupodivu" víc hodí klávesnice :D
Někdy to zákazník ví a nesežene. Pak je ještě jedna možnost - místo 20kKč za jednu licenci licenci komerčního produktu, který to zvládne na 90% se dá vzít open source, který zvládne 80% a zaplatit 30kKč studentovi, který "přiohne" kritický featury podle předtav zákazníka a licence jsou zadarmo na kolik chce komplů. Zákazník má, co potřebuje, společnost lepší open source produkt a student má legální brigádu a může si do životopisu hodit referenci na úspěšný open source produkt... A spokojení jsou všichni (kromě marketingu velké firmy, která nechce nabídnout řešení pro zákazníka, ale těm to patří).
Nejsem priznivec bloatware (coz gcc jiste je), ale neuveritelne me vytaci, ze nekdo hodla tuto "hracku" (tcc) povazovat za plnohodnotnou nahradu gcc.
Gcc je jedna z mala VYNIKAJICICH veci ve svete opensource - a ani clang/lvvm stale neni plnohodnotnou nahradou za gcc.
Take muzeme misto neuveritelne slozitych bot chodit bosi, misto neuveritelne slozite tkanych latek muzeme chotit v medvedich kozesinach a misto neuveritelne slozite pripravy modernich jidel jist korinky. Ne dekuji.
gcc také mají mezi "harmful" http://harmful.cat-v.org/software/
Chápu některé ušlechtilé pohnutky, ale čekal bych, že forma následuje obsah. A že výsledný program nebude primárně omezován maximálním počtem řádků, nýbrž nějakou rozumnou množinou užitečných vlastností. Pokud se je podaří implementovat stručně a efektivně, je to super, ale to by měl být až sekundární cíl. No ale kdo si hraje, nezlobí.
Myslim, ze jsi hezky vystihl muj vlastni pocit z toho. Ten cil (byt jako Unix, kazdy program dela jednu vec a poradne) je uslechtily, ale podminovat to konkretni technologii je hloupost.
Ale kdyby nekdo zalozil operacni system na Lispu.. (a taky jako toolbox) to by mohlo byt zajimave. (Vlastne uz to skoro existuje - Emacs.)
Ano zato vy o tom viete vsetko.... Vzdy ked citam ako sa niekto ohana produktivitou prace tak rozmyslam co take strasne zlozite robi aby sa musel 10x za minutu prepinat medzi oknami, spustat nove programy atd... Pre mna za mna pouzivajte hocico akurat chcem vydiet ten realny vystup ako vasa produktivita obsrovsky rastie. A ked niekto napise, ze mu to navyse zerie vykon grafiky tak neviem, pracujete alebo co vlastne robite???
Takže vám to vysvětlím - produktivita práce u mne stoupla tím, že teď v klidu pracuju, zatímco s GnomesHellem jsem si musel po pěti minutách činnosti zajít na čtvrt hodinu na cigáro, abych se uklidnil z těch přiblblých obrovských ikon a vyjíždějících panelů. Stačí?
Co se týče 3d grafiky, tak dělám mimo jiné i modelování a grafárnu mám pasiv, aby mi tu nehučel větrák a zapnuté 3d efekty mi shodí fps na polovinu.
Pokud vám dělá dobře se po ránu hned začít navážet do někoho, koho ani neznáte, tak to asi bude tím, že používáte Gnome 3 a jste z něj vystresovaný. Možná by vám pomohlo také přejít na nějaký decentnější systém.
takze si to zratame..... 5 minut pracujete 15 minut fajcite takze za den ste realne makali 2hodiny a mohlo za to gnome 3. Kazdopadne vasa efektivita musela byt aj predtym na nemalej urovni ked vam stacili 2 hodiny prace. Teraz predpokladam po prechode, nema sef hlupe poznamky na vasich kolegov? nieco v zmysle efektivita a tak... Ale je fajn, ze vasmu rozletu uz nic nebrani a stacilo tak malo, 2000 riadkov kodu. Ja byt vami to poslem autorom, urcite sa na ich wiki budete vnimat na cestnom mieste nieco ako success stories.
S Gnome byl cyklus 20 minut, 5 minut práce, 15 cigárko, za 8 hodin 24 cyklů po 5 minutách práce, 120 minut denně odpracovaných.
Bez Gnome je cyklus 30 minut, 15 minut práce, 15 minut cigáro, protože pak ho stejně nějaké blbost vytočí, nebo se přihlásí závislost. Za směnu 16 cyklů, odpracuje celých 240 minut.
Zdvojnásobil produktivitu, ale furt je na 50% toho, co zvládne jeho kolega, který nepotřebuje čmoudpauzu...
Takže prostor ke zlepšování by tady ještě byl.
Ono sa to tiez netykalo window managera narazal som na tie keci o uzasnej produktivite. Je prepnutie sa medzi programami a pripadne spustenie dalsieho cinnost ktora tak velmi zabera cas? Kolkokrat to treba robit za minutu? Alebo je to nechut k prostrediu (dizajn, celkova filozofia,atd) a hladanie zastupneho dovodu?
dwm som relatívne dlho používal (prešiel som naň z wmii), ale oba mali problém s tým, že si ku NB pripájam druhý monitor a nezvládali prihadzovanie a vypínanie druhého monitoru. Zmenilo sa to za ten čas čo som to už nesledoval? (asi tri roky).
Nakoniec som zaparkoval na xmonad, kde mi toto moje šaškovanie pripájaním a odpájaním monitora funguje asi najkonfortnejšie. (Ale zas nie som ktovieaký kamarát s haskelom a tom som sa už pár krát pokúšal prísť na to ako to vlastne funguje. ;-) )
xrandr je jasný. Len pri wmii sa mi po pripojení druhého monitora (boli rôzne veľké) čiastočne stratil status riadok (bol naspodku), lebo na druhom monitore bol mimo jeho rozsahu. dwm zase urobil kópiu všetkych "virtuánych plôch" a mal som ich teda zdvojené.
wmii som mal rád. len mi prestal vyhovovať pri pripájaní druhého monitora. Bol to môj prvý tilling WM a vydržal som pri ňom veľmi dlho (predtým som používal WindowMaker (najdlhšie) a pekwm).
Neviem, či by som si znovu zvykol na stĺpcový tilling, ako to používa wmii (používal?), už som pridlho používal xmonad (predtým ešte dwm). Ale už je to veľmi dlho čo som to nepoužíval a tak neviem ako sa terajšie verzie popasujú aktuálne s dynamicky meniacim sa počtom monitorov. ALe blížia sa vianočné sviatky, možno bude menej roboty a bude čas si to znova vyskúšať.
Je to samozřejmě extrém, ale ve spoustě věcí mají pravdu. Bloatu je všude kolem mraky, je potřeba vyvažovat opakem z druhé strany. A ta striktní pravidla v konečném efektu dávají smysl, boj s bloatem je bez nich asi nereálný.
Kdyby se každý vývojář od nich naučil třeba jen to, že je nutné se nad těmito otázkami zamýšlet a že jejich kód bude muset někdo další po nich udržovat, už jen v tom by jejich úsilí mělo přínos.
> Návrhové vzory byly zavedeny právě z těchto důvodů.
To ovsem nic nemeni na tom, ze jako reseni je to naprosty omyl. Spravne reseni by bylo ony "navrhove vzory" zahrnout do abstrakci prislusneho jazyka - jako to treba dela Common Lisp, a proto v nem neco jako "navrhove vzory" neexistuji.
+1
Je neuvěřitelné co se kolem Design Patterns naakumulovalo za cargo cult, že i po dvaceti letech se stále můžeme dočkat perel typu "nauč se návrhové vzory" nebo "v Lispu návrhové vzory neexistují". Přitom si stačí přečíst předmluvu od GoF, na Amazonu je k dispozici zdarma.
No, konkretni odpoved by asi zavisela od problemu a od jazyka, ale vetsinou asi.. zadnou?
Pokud chcete napojit neco nekam, kde se ceka neco jineho, pak to musite napsat tak jako tak. Fakt, ze to pojmenujete vznosne "adapter", na citelnosti nijak nepomaha (a tedy to neni vhodny priklad pro vase tvrzeni).
Adapter je navic dost specificky vzor pro jazyky typu Java (staticky typovane OOP). Ale odpovidajici problem da resit mnoha ruznymi zpusoby, v zavislosti na jazyku.
Vic informaci o tom, na co narazim, tady: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures
Aha, už asi vím, kde je problém. Já chápu design patterns z větší části jako záležitost architektury programu. Proto se také jmenují DESIGN patterns, ne třeba LANGUAGE patterns. Konkrétní implementace patternu v konkrétním jazyce je podružná věc.
Takže když vidím v kódu (poznámce, jménu třídy), že je něco Adaptér nebo Singleton (nebo jiný pattern), tak vím, jak to funguje, co to má dělat bez toho, že bych to musel hlouběji zkoumat. A o to jde.
> Niektore vzory nemaju velmi siroke uplatnenie.
To ani mít nemusí. Stačí když se často vyskytují v některých specifických oblastech. Víc než na jazyce závisejí použité vzory na tom, co se zrovna řeší. Třeba Adaptér je skoro k ničemu někomu, kdo může věci přepisovat podle libosti. Mají o něj díky tomu přijít lidé, kteří musí udržovat binární kompatibilitu třeba půl roku zpátky? A o tom, jestli je nějaké uplatnění dost široké, nebo ne, bych se opravdu nerad s někým hádal.
Jinak receno, je to pro tebe proste terminologie. Ale ta terminologie ma jiste predpoklady, napr. O~OP. Kdyz budu mit v Lispu multi~metodu na dvou objektech, mohu tam napsat, ze je to Visi~tor, nebo je to hlo~upost? Pritom arch~itekturalne je to stejne.
A pokud to tedy beres jako zalezitost architektury a ne implementace, jak to zlepsuje citelnost pro~gramu (to bylo tve puvodni tvrz~eni)? Mozna to zlepsuje citelnost nejakeho popisu archite~ktury (i kdyz i tam o tom mam pochybnosti, jelikoz je to v podstate termino~logie navic), ale programu samotneho?
T.o z.á.l.e.ž.í, j.e.s.t.l.i tu m.e.t.o.d.u p.o.u.ž.í.v.á.š jako V.i.s.i.t.o.r nebo ne.
Č.i.t.e.l.n.o.s.t p.r.o.g.r.a.m.u to z.l.e.p.š.u.j.e jak jsem psal výše - pokud ze jména t.ř.í.d.y nebo p.o.z.n.á.m.k.y v.y.p.l.ý.v.á DP, tak rovnou vím, co ta třída z.h.r.u.b.a dělá, jaké bude mít č.á.s.t.i./.m.e.t.o.d.y atp. A n.e.m.u.s.í.m ji r.o.z.p.l.é.t.a.t úplně od z.á.k.l.a.d.u.
Ten radoby-antispam-blacklist me taky stve, obtezoval me uz vicekrat pri zcela korektnich prispevcich.
Vyzkousime, zda je ucinny na skutecne spamy:
Kupte si viagru zvetsi se vam penis budete mit pero jako kladu, stoji u nas pouze 10,000$ a poslete nam zalohu 500$ na konto Umba Lumba, 120 00 Nigerie.
A co třeba továrna nebo obecně třída, v jejíž instanci si něco připravím, inicializuji a z které pak vycházejí další objekty? A je to navržené tak, že ten první udělá při inicializaci co nejvíc práce a metodu na generování objektů lze volat z různých vláken. A ten druhý objekt už používám jen v rámci jednoho vlákna, takže se v něm nemusí řešit žádná synchronizace a je to díky tomu rychlejší a spolehlivější.
1) je to terminologie – každý obor vytváří různé kategorizace, třídí věci do škatulek a pak nad nimi rozjímá :-) SW inženýrství není výjimkou.
2) je to sbírka ověřených nebo alespoň vyzkoušených postupů, ze které se programátor může inspirovat, a může si přečíst o výhodách a nevýhodách jednotlivých vzorů – a podle toho se lépe rozhodnout, jaký postup pro řešení daného problému použít. Stejně tak existují návrhové vzory pro relační databáze nebo třeba sbírky algoritmů… Nadpis v nějaké knížce spíš bude „Tovární metoda“ než „tato funkce vraci novou instanci objektu x“ :-)
Ano, to jsem uz napsal, ze je to terminologie, ale jeji prinos je podle me (casto) diskutabilni. Treba v pripade tovarny si to myslim celkem urcite.
Nicmene takova terminologie jeste sama o sobe nezprehlednuje zapis programu, mozna zprehlednuje komentare, ale to je tak cele. Takze i kdybych uznal, ze je to uzitecna terminologie, porad zbyva dolozit puvodni tvrzeni z tohoto vlakna.
Tady je to spis historicke, ale zrovna "prirozena cisla" zase tak uzitecny pojem nejsou, pokud uvazime, ze v (matematicke) praxi se pouzivaji asi tak stejne casto (a mozna i casteji, specialne v CS) nezaporna cela cisla jako pozitivni cela cisla. Spis by se v praxi hodilo nejake kratke oznaceni pro "mnozinu nezapornych celych cisel mensich nez N".
> pokud uvazime, ze v (matematicke) praxi se pouzivaji asi tak stejne casto (a mozna i casteji, specialne v CS) nezaporna cela cisla jako pozitivni cela cisla.
Definice prirozenych cisel casto zahrnuje nulu.
> Spis by se v praxi hodilo nejake kratke oznaceni pro "mnozinu nezapornych celych cisel mensich nez N".
Pro to se obcas pouziva primo cislo N (tedy to cislo, ktere je mezi), v souladu s definici z teorie mnozin, ktera konstruuje prirozena cisla jako mnoziny vsech jejich predchudcu. Ale IMHO to je matouci znacneni.
Nezbývá, než souhlasit. Vyznávám Occamovu břitvu i Euxupéryho tvrzení "Dokonalosti se nedosahuje tehdy, když už se nedá nic přidat, ale tehdy, když už se nedá nic odebrat". ale tohle je fakt moc i na mě.
Návrhový vzor se nesmí přeceňovat, ale pro zjednodušení návrhu a údržby je fajn. I dokumentace je o řád jednodušší, když se tam napíše "... byl využit návrhový vzor x" než popis vlastního řešení.
Navíc averzi k C++ taky nechápu. Jazyk by neměl být cíl, ale prostředek, jak něčeho dosáhnout. Když budu mít v okně pět tlačítek, mám několik možností, jak to udělat:
1) Napsat si kód pro jedno tlačítko a s pomocí Ctrl-Cizí + Ctrl-Vlastní vytvořit v kódu jeho klony s tím, že u všech klonů změním názvy dotčených funkcí, jejich volání, referuju na jinou bandu proměnných atd. Takhle pohnojený pole pro růst chyb se málo kdy vidí a takový program těžko bude dělat něco dobře. Nehledě na to, jaký má člověk čichový vjem z pole, na který právě zemědělec vyšplíchá cisternu močůvky. Takže tudy ne.
2) Napsání kódu pro tlačítko, kde je funkcionalita popsaná abstraktně a zpracovává se nějaká struktra, co popisuje chování, pozici, nápis, callbacky a předává se každé funkci. Takže si musí hlídat nejenom data, ale i volání funkcí a jejich parametry a je zase po kotníky v mrvě.
3) Jít na to objektově, vytvořit třídu pro tlačítko a do okna nasázet jejich instance. V podstatě je to jako řešení 2, ale s tím rozdílem, že nemusí ručně definovat strukturu pro funkce a jejich volání, strukturu pro data, inicializace, uvolňování paměti,... Všechno to splácá kompilátor (ono vlastně C++ byl prekompilátor, co automaticky přepisoval konstrukce do C a redukoval tak chyyby a zbytečnou práci). Takže vytvoření instance a její inicializace smrdí chybama o poznání míň. Navíc se to mnohem víc blíží stavu, kdy programátor myslí na řešený problém a ne na to, jak obejít omezení prostředí a je větššance, že najde efektivní řešení.
A to nemluvím o dědičnosti, kde při pokusech o OOP v C jedna struktura odkazuje na druhou, musí se hlídat typ a pořadí dat ve strukturách potomků, nefunguje automatická kontrola, která by varovala před jiným návratovým typem... Neexistenci výjimek a zaplevelení kódu pomocí GoTo... Neexistenci výjimek a zabrání návratové hodnoty funkcí chybovým kódm, jeho neustálým testováním a vracením hodnot pomocí pointerů, který můžou "uletět" a něco přepsat...
V mým případě Occamova břitva bere duplicity v kódu i management spojený se správou dat. Zůstane ta třída v C a ještě osekaná o duplicitní funkcionalitu, kterou může dělat předek...
Takže tohle hnutí beru za pochybnou sektu, která považuje C za posvátný a odmítá jeho znesvěcení ať už objektovou nástavbou, nebo použitím standardních dokumentovaných postupů a staví se dokonce i proti ukládání dat v CSV.
Z 99% souhlas.
Tedy az na "zapleveleni kodu pomoci GoTo" - dobre pouzite goto muze C kod
velmi vyrazne procistit a z prehlednit - typicke pouziti, kdy je IMHO goto v C
neprekonatelne je treba takovyto "construktor":
struct SomeStruct *some_struct_new(..., int *errcode) { int ret = OK; struct AStruct *a = NULL; struct BStruct *b = NULL; struct XStruct *x = NULL; struct SomeStruct *self = NULL; a = a_struct_new(...); if (a == NULL) { *errorcode = ERROR_A; goto error; } ... b = b_struct_new(a, ...); if (b == NULL) { *errorcode = ERROR_B; goto error; } ... x = some_struct_new(a, b, ...); if (x == NULL) { *errorcode = ERROR_X; goto error; } ... self = (struct SomeStruct*)malloc(sizeof(struct SomeStruct)); if (self == NULL) { *errorcode = ERROR_MALLOC; goto error; } ... exit: return self; error: if (x != NULL) { some_struct_destroy(x); x = NULL; } if (b != NULL) { some_struct_destroy(b); } if (a != NULL) { some_struct_destroy(a); } self = NULL; goto exit; }
Zde mam jenom jeden return, mam oddelenou "cleanup" cast, kde mam i zarucenou
spravnou posloupnost ruseni struktur a hlavne je "hlavni kod" minimalne
zatizen obsluhou chyby.
Pozor, vyjimky maji vyrazne lepsi uplatneni pokud je potreba predat vyjimku z vnitrni funkce ven. Tam kde nelze ven vratit vyjimku mi konstrukce s goto pripada o chlup lepsi, protoze clovek nemusi premyslet nad tim kde a jak se vyjimka konstruuje (je to objekt) a kde destruuje.
Vyse uvedeny kod je spise priklad pro destruktor nez pro vyjimku.
Jenomže stačí, když se najde nedouk (takových v téhle sektě bude plno, když nepobrali ani princip OOP) a hodí GOTO ven z funkce, zůstane rozhozený zásobník... Je fajn, že vy znáte meze kde to použít, ale podle toho se nedá zobecňovat.
A stejně to pak vede k obsazení návratové hodnoty a jednoho parametru funkce ukazatelem na instanci, výjimka a OOP je čistší. Jejich posvátný C už patří jenom do embedded světa a psát v něm na PC - s výjimkou školních projektů, částí systému a unit testů embedded software - je pomalu ostuda.
Samozrejme, temer kazdy jazykovy konstrukt se da zneuzit. Jen jsem chtel ukazat, ze absolutni slepe odsuzovani "goto" je zcestne. Navic podle me je v C mnohem vice mnohem horsich veci, ktere mohou zpusobit (a take zpusobuji) velke problemy (pointery, alokace pameti, ..)
A protoze jsou systemy, ktere jsou psany v C, a je VYZADOVANO aby zustaly v C, tak zadne vyjimky pouzit nelze.
90% "programatoru" vzivote nevidelo co z toho jejich kodu ve finale vyleze ... a velmi casto tyto "prasarny" vedou k vyrazne rychlejsimu/mensimu/... vysledku. OOP je pak velmi vyzdvihovany princip, ktery je casto naprosto nanic a jeho pouziti vede naopak k naprosto neprehlednemu a nespravovatelnemu vytvoru.
Podobne jsme na to s vyjimkama a dalsima "ficurama" ... nic nepotesi vic, nez kdyz na me nekde vyskoci "neosetrena vyjimka" + nejaky kilometrovy cosi ... proto, ze ten mastic co to napsal proste neresi, co funkci preda, ale proste ji zavola, klidne se stringem misto cisla na vstupu ...
Ale to co rikate plati o uplne vsude. Jestli Vam dobre rozumim, rikate v podstate toto:
A ja pak rikam:
Reaguju predevsim na to, ze programator nemusi vubec tusit jak vypada OOP a presto muze psat velmi dobry a kvalitni kod, a to i presto, ze pouziva tzv "prasacke" postupy (trebas goto ven z funkce), proste proto, ze vi co to dela a pocita s tim.
Ostatne procesor/assambler stejne nezna nic jinyho nez skok na nejakou adresu. Takze z libovolnyho kodu nakonec vyleze cosi plne "goto".
Nemluve o tom, ze se dycinky rozesmeju, kdyz nekdo pise hello world (asi bych mel spis plakat) a potrebuje na to 5MB binarku a samozrejme si na to nejdriv vyrobi objekt ... a aby mu to vubec bezelo, je treba jeste nainstalovat 500MB .NET
Kromě JMP + JMP existuje i CALL + RET! A ta druhá dvojice, narozdíl od první, nechá něco v zásobníku! Navíc je většinou limitovaný počet registrů, takže se při volání funkce data z volající naperou do zásobníku.
Takže o někom, kdo použije GOTO z funkce i o jeho programech si myslím svoje, zvlášť pokud to obhajuje, že "stejně je to interně JMP". Nechat bordel v zásobníku je zhovadilost a po čase nutně vede k stack overflow se vším, co z toho plyne. Stabilitou aplikace počínaje, pověstí programátora pokračujíce a týdny hledání příčiny konče (protože aby to ten vůl našel, musí se napřed naučit, jak to vlastně celý funguje a to za večer nedá).
To závisí na architektuře. Například na IBMských mainframech analogie CALL uloží do daného registru adresu následující instrukce a kus PSW a analogie RET obnoví z daného registru ten kus PSW a skočí na adresu v něm. To mimochodem znamená, že volaná rutina musím vědět, jak byla volaná (usus je, pokud si pamatuju, to předávat v registru 13, ale nic člověka nenutí to tak udělat a jsou situace, kdy to ani udělat nejde). Co pak volaná rutina s tím registrem udělá, je její věc, ale žádný zásobník tam nehledejte.
A jen tak mimochodem, v C je label lokální identifikátor viditelný jen v dané funkci, takže skok do jiné funkce přes goto udělat nelze (narozdíl třeba od Pascalu).
> Nechat bordel v zásobníku je zhovadilost a po čase nutně vede k stack overflow se vším, co z toho plyne.
Delals nekdy neco v asm? Nebo ses aspon dival co ti vygeneruje prekladac?
Treba na x86 se to dela tak ze si pri vstupu do funkce zalohujes aktualni hodnotu registru SP (stack pointer) do registru BP. Provedes kod funkce. A pred returnem SP zase obnovis. Takze na zasobniku zadnej bordel nezustane i kdybys preskocil do funkce ktera ocekava uplne jinej stack frame...
Dělal. Z80, x86, 8051, AVR, DSP od TI, MSP430, H8/300H, SH2A, SH4, PowerPC, ARM7TDMI, ARM9EJ-C, Cortex M0, Cortex M3. Když píšeš bootloader nebo system itni, a je to ve tvojí režii, moc se k výsledkům překladače nedostaneš. A registr BP jsem mimo x86 neviděl nikde :P Navíc výsledke překladače hodně závisí na platformě a na překladači, jiný věci fluše GCC, jiný IAR EW, jiný Keil... Liší se i správa paměti.
Když return přeskočíš, neobnoví se vůbec nic. To je jednoduchý. A soustředěnýmu náporu blbosti neodolá nic. Stačí, když někdo místo "return" napíše "__asm{ret}", protože si všiml, že to ušetří pár bytů ve FLASH a je vymalováno...
Navíc v komerčním prostředí u embedded systémů je často požadavek na multiplatformní podporu. Co funguje na jednom broukovi v jednom kompilátoru, to na druhým dělá nečekaný žertíky...
A nebyly vase programy nahodou prilis velke? 2000 logickym radkam dokazu udelat codereview sam, a verim, ze v suckless komunite ty kody precetlo hodne lidi. A verim, ze je opravdu mala moznost zaneseni chyby dobre mirenym zasahem (jednim! Vice zasahu by tak maly kod nemel potrebovat).
Ja sam mam problemy s tim, ze me programy obcas kompiluji ale nefunguji. Ale velmi casto je to tim, ze to po mne nikdo necetl, a obcas jsem to dokonce nepsal tak aby to po mne nekdo cetl (protoze to melo byt "provizorni reseni").
Takze i mne idea prijde spravna. Provedeni ("zakazani" nekterych jazyku/formatu) uz ne. V C i C++ se da psat spatne i dobre. Spis mam pocit, ze spatni programatori radeji delaji v C++ nez v C, zatimco dobrym by to melo byt celkem jedno (zvoli jazyk podle naroku projektu, psat jadro v C++ je podobne nepohodle jako psat GUI v C).
Nejde o velikost, ani o styl psaní, ale o princip. Kompilace bez chyb neznamená NIKDY kód bez chyb a kdo to věřejně napsal, měl by si kleknout do kouta na hrách a nezvednout se, dokud nepřečte tisícístránkovou bichli o ladění software a nepochopí ji.
Ten, kdo použije úpravu header file jako user options a neudělá na to ani compile time aserty pro všechny kombinace, nepatří za klávesnici, ale do šaškecu pod sedativa. Na to se přece nedělá ani review a kompilátor miliardy věcí nevidí.
Kompilátor nemusí přijít na chybu ++i místo i++... Nepozná chybějící aserci na velikost pole v jiným modulu, kde se pomocí toho i indexuje... Na wild pointer hodí jenom warning, a to ještě pokud je povolený (a hodně tukanů nepoužívá warningy, protože je to otravný)... Nepozná overflow / underflow hodnot, pokud jsou meze v rozsahu proměnné... Nezařve, když do proměnné typu COLOR uložím hodnotu typu WIDTH, pokud tam někdo hodí explicitní typecast nebo to "protáhne neutrální proměnnou" typu int s nicneříkajícím jménem param123...
Ehm ... jak bylo receno ... pokud nekde napisu (trebas) ze x = x+2 ... tak to jiste kompilaci projde ... ale asi se budu divit, ze moje funkce na zdvojnasobeni jaksi nenasobi ... a podobnych minel se da na 2k radku nasekat desitky. Takze to kompilaci zcela spolehlve projde, ale delat to bude zcela neco jineho, nez autor ocekava.
Otázka je, co považujete za obfuskaci.
Já byl strašně překvapen, když jsem v potřeboval spočítat, kolik bloků paměti o velikosti K potřebuju na data o velikosti N, napsal jsem:
(N - 1) / K + 1
a bylo mi vynadáno, že tomu nikdo nerozumí, že správně to mám napsat:
N % K == 0 ? N / K : (N / K) + 1
(všimněte si toho závorkování, normální člověk asi neví že dělení má přednost před sčítáním, ač se to učí už na prvním stupni ZŠ a respektuje to drtivá většina programovacích jazyků).
Mě osobně tedy více obfuskuje to "správné" řešení.
Jo, komentář. Jeden z dalších principů, které jsem musel dodržovat, bylo co nejméně komentářů. Proč? Protože když se hrabe do kódu, většina programátorů se vykašle na příslušnou úpravu komentářů a není nic více obfuskujícího než komentáře popisující jiný kód, než ten, který vidíte.
Ale zpátky. Bylo to v týmu, který dělal různé komunikační protokoly a zarovnávat data musel každý několikrát denně. Přesto pro ty programátory bylo naprosté novum, že se to dá dělat tak jednoduše. To jsem fakt nechápal.
To je otázka, jaké ty komentáře jsou. Pokud je to stylem:
// Do proměnné A vložíme součet B a C
a = b+c;
Tak takové komentáře opravdu radši nepsat.
Komentáře by měly popisovat věci, které se z kódu zjišťují obtížně. Třeba "co k čertu má tahle třída vlastně dělat". Není nic horšího, než mít projekt s desitkami nebo i stovkami vzájemně provázaných tříd, u kterých není vesměs ani čárka o tom, k čemu slouží a jak se vážou na ostatní a člověk to musí složitě louskat z kódu. Ideálně u každé netriviální funkce krátce popsat její kontrakt, hlavně s důrazem na různé speciality. Dál pak u netriviálních kusů kódu popsat co dělají a u překvapivých proč tam jsou.
Bohužel, pokud ten kód má už nějakou historii, tak se stejně louskání kódu nevyhnete, protože prostě nevíte, jestli ten komentář popisuje "jak to je" nebo "jak to bylo před deseti lety". Už jsem viděl hodně krásně okomentovaných tříd, kde ale metoda s deseti parametry měla podle komentáře parametry jen dva a vracela jiný objekt než podle komentáře.
b = (N + 1)/(K - 1);
2003 se_addi r3,0x1 ; N,1
18DF84FF e_addi r6,r31,-0x1 ; r6,K,-1
7CE333D6 divw r7,r3,r6 ; r7,N,r6
D271 se_stw r7,0x8(r1) ; r7,b(r1)
12 bytes
b = (N % K == 0) ? N / K : (N / K) + 1;
7CDFF1D6 mullw r6,r31,r30 ; r6,K,r30
0736 se_subf r6,r3 ; r6,N
2A06 se_cmpi r6,0x0 ; r6,0
E205 se_bne 0x3DF82
7CE3FBD6 divw r7,r3,r31 ; r7,N,K
D271 se_stw r7,0x8(r1) ; r7,b(r1)
E804 se_b 0x3DF88
18FE8001 e_addi r7,r30,0x1 ; r7,r30,1
D271 se_stw r7,0x8(r1) ; r7,b(r1)
24 bytes
b = N / K + (N % K) ? 1:0;
7CFFE9D6 mullw r7,r31,r29 ; r7,K,r29
0737 se_subf r7,r3 ; r7,N
04D7 se_add r7,r29
2A07 se_cmpi r7,0x0 ; r7,0
E604 se_beq 0x3DF9E
4817 se_li r7,0x1 ; r7,1
D271 se_stw r7,0x8(r1) ; r7,b(r1)
E803 se_b 0x3DFA2
4807 se_li r7,0x0 ; r7,0
D271 se_stw r7,0x8(r1) ; r7,b(r1)
22 bytes
b = N/K - ((N % K) > 0);
05CF se_mullw r31,r28 ; K,r28
7CFF1850 subf r7,r31,r3 ; r7,K,N
7C0700D0 neg r0,r7
7C073878 andc r7,r0,r7
69F7 se_srwi r7,0x1F ; r7,31
07C7 se_subf r7,r28
D271 se_stw r7,0x8(r1) ; r7,b(r1)
20 bytes
Vitezem se stava povodni autor tesne nesledovan a :D, a rozpadlo se mi formatovani ale to uz rozlustite.
Bohužel, koho chleba jíš, ...
Taky mě štve že dnes se za programátora považuje každý, kdo umí zapnout počítač, v životě neslyšel slovo algoritmus, a když vidí dobře napsaný program, tak si může hlavu ukroutit, protože běžné efektivní postupy jsou nad jeho chápání. Pak člověk vidí takové hrůzy, jako že si tým napsal vlastní String library (protože ta standardní je samozřejmě špatně, plná chyb a neefektivní), a pak ji používá způsobem, že když potřebuje od stringu odříznout prefix REQ: tak napíše "pokud string obsahuje dvojtečku tak najdi pozici první dvojtečky a pokud je 4 tak ho až k dvojtečce odřízni), místo aby prostě po kontrole že začíná REQ: uřízl první čtyři znaky. A důvod takového nesmyslu je, že odříznutí prvních čtyřech znaků je nečitelné, protože programátor jejich kalibru si prostě neumí spočítat počet znaků v konstantě "REQ:"
Podobně jsem viděl (nekecám, opravdu) coding standars, kde se psalo, že když multithreadový program přistupuje ke globální proměnné, tak sice bývá zvykem ten přístup ošetřit mutexem, ale protože je malá pravděpodobnost, že se tam ty thready potkají, tak používaní mutexů je zbytečné a proto se používat nemají, aby se zbytečné nemrhalo CPU timem.
Bohužel takových lidé se živí programováním čím dál víc.
> A důvod takového nesmyslu je, že odříznutí prvních čtyřech znaků je nečitelné, protože programátor jejich kalibru si prostě neumí spočítat počet znaků v konstantě "REQ:"
To skutečně nečitelné a problematické být může – ta konstanta je definována někde nahoře a čtyřka je zapsaná kdesi uvnitř kódu. Co se asi tak stane, když někdo rozhodne o změně hodnoty konstanty? Přepíše to nahoře a dole bude chyba.
Měl bys tu 4 odvodit buď z délky řetězce nebo si pro ni definovat konstantu hned vedle té obsahující text a přidat tam komentář, že tyto dvě konstanty je potřeba udržovat v souladu.
To jsi ten priklad nejspis pochopil spatne, oni tam tu konstantu 4 porad maji, akorat se pouziva jinak.
Ale fakt je, ze casto to delam, nez abych pojmenovaval konstantu, radeji to spocitam. Duvodem je lepsi citelnost - pokud potrebuji delku na stejnem radku (typicky priklad je strncpy), pak zavadet konstantu nekde na zacatku bloku citelnost spis zhorsuje.
No jestli celá ta idea suckless stojí na myšlenkách z té wiki http://harmful.cat-v.org, tak potěš koště. Schválně jsem se koukl na důvody proč je špatné C++ a našel jsem :
1) "Rozhovor" se Stroustrupem, který je tak provalený, že se divím že na ten hoax ještě někdo skočí. A i kdyby to čtenář neznal, tak je to evidentní pičovina.
2) Hromadu citátů o tom, že je C++ špatné. Když budu hledat, tak najdu dost citátů pro podporu jakéhokoliv žvástu, takže zase nic.
3) Odkazy na zdroje. Rozklikl jsem si první dva a měl jsem chuť si rvát vlasy. To není porovnání C a C++, to jsou ukázky chyb, které udělá někdo, kdo s C++ začíná a neví která bije.
Na víc nemám zatím sílu. Jako hate a trolling to ujde. Jako podpora pro jakýkoliv rozumný návrh software je to tak na facku. Pletu se a našel tam někdo něco lepšího?
Nektere myslenky jsou hezke (ja sam pouzivam "dmenu" - ale v xmonad), ovsem nektere jsou zcela silene - pripomina mi to ruzne "hnuti proti pokroku" - at uz ruzne americke nabozenske komunity (amishe), nebo ruzne hippies, deti zeme apod. - vsichni maji jednu spolecnou myslenku - ze urcita technologie je v poradku, spravna a dobra, ale vsechno nadto je "zle" a musi se zakazat.
V pripade amishu to je v podstate kazda technologie vznikla od 17. stoleti, v pripade hippies vsechno co pouzivaji jejich rodice a v pripade deti zeme je to cokoliv cemu nerozumi.
Mimochodem opravdu nechapu jak muze mit nekdo motto "worse is better"...
There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.
Ono teoreticky to zní hezky, ale všeho moc škodí. Hlavní myšlenkou zřejmě nebyl polofunkční nekonfigurovatelný SW, který dokáže používat jenom programátor. Zatím to vypadá, že to motto vzali doslovně...
Koukám na mého oblíbence Python a je taky v harmfull. :) Nevím proč, ale asi proto, že objektové programování je obecně v harmfull.
Jenže to je věc kterou začínám číst čím dál častěji. Já teda fakt nemám kapacitu na to odhadnout jaké paradigma příjde po OOP, ale zdá se mi, že už to bude brzo.
Je pravda, že z oop se poslední dobou udělal jakýsi kargokult. Ale shrnout ho šmahem je taky blbost.
Momentálně se všude možně cpou prvky z funkcionálního programování. Jak bude přibývat jader a vláken, tak se víc a víc vyplatí neměnné objekty, které se nemusí zamykat. Taky by se mi líbilo, kdyby se do mainstreamu protlačil systém tříd z Haskellu. Nadějné náznaky vidím v C++ (fuj) přes boost (ještě víc fuj) :)
Funkcionálne?
V prvom OOP rieseni su metody pevne zviazane s datami. Ked chcem objekt rozsirit o inu funkcionalitu musim pouzit dedicnost alebo mixiny. Pricom vzdy dedim vsetky metody z rodica.
V druhom pripade pouzivam objekt list na ktory si vytvorim sadu funkcii (modul) Stack takze list pouzivam ako zasobnik. Ked potrebujem inu sadu funkcii pouzijem iny modul ale stale pouzivam ten isty objekt. Dalsia vyhoda toho funkcionalneho riesenia je ze cely zasobnik je immutable.
LOL. Muzete mi prosim vysvetlit, proc je dle Vas na produkcni nasazeni lepsi c++ ?
Prehlednejsi kod? NE!
Snadnejsi udrzba? NE!
Lepsi prenositelnost? NE!
Snadnejsi deployment? NE!
Jednodussi testovani? NE!
Mensi riziko padu? NE!
Vyssi vykon (CPU)? Mozna, ale v 99% pripadu irelevantni (mysleno tak, ze sitova latence je radove vyssi nez cas zpracovani pozadavku pythonem).
Setkal jsem se s podobnymi nazory, ktere ovsem ve vetsine pripadu zastavali lide, kteri (a) vubec nic nevedeli o vyvoji, a pouze "vedeli, ze v C++ pisi profesionalove" (=cargo cult), nebo (b) umeli jen jeden jediny jazyk ve kterem pracovali 20 let a kdyz jediny nastroj, ktery mate je kladivo.. vse vypada jako hrebik.
Menší riziko pádu rozhodně ano. Jako každý jazyk, který je staticky kompilovaný.
Síťová latence je pro výkon irelevantní, proto se taky webové aplikace navrhují posle počtu požadavků za sekundu a ne podle latence. Nad určité množství požadavků za sekundu začne být C++ o dost lepší.
Vzhledem k tomu, ze jsem stravil pravdepodobne stovky hodin sveho zivota hledanim nejake obzvlaste vypecene "pametove chyby" v C/C++, tak si troufnu tvrdit, ze staticka kompilace s rizikem padu souvisi vicemene nijak.
Podle toho co pisete o webovych aplikacich by mely byt vsechny serioznejsi psany v C++. Coz se zjevne nedeje. Abyste mi dobre rozumel - ja naprosto souhlasim, ze v EXTREMNICH a velmi vzacnych pripadech muze byt pouziti nejakeho kompilovaneho "rychleho" jazyka lepsi nez nejakeho interpretovaneho/bytecode jazyka. Ovsem znovu zduraznuji - v EXTREMNICH A VELMI VZACNYCH PRIPADECH.
Divil by ses, ale casti nekterych webu, ktere jsou vytezovany, jsou kompilovany trebas jako modul do apache.
A proc to tak neni u vetsiny webu? Protoze weby z 90% nic narocnyho nedelaji, a interpret tomu bohate staci. Svoji (vyrazne) horsi vykonnost pak nahrazuje snadnou modifikaci. V mnoha pripadech se pak problem s vykonem webu samotnyho resi vsemoznych cachovanim obsahu ... protoze se stejne i tom alo co web dela porad dokola opakuje.
Mimochodem, jisty pravidelny prispevatel by ti jiste mohl povyprave o tom, jak se M$ roky snazil prepsat widle do .NET ... a ve finale to cele zahodili, protoze se to nedalo zprovoznit ani na nejvykonnejsim zeleze.
Pro zajimavost, mam tu uzasnou .NET aplikaci ... scroll gridu zatezuje 2jadro na 80+%. Kdyz sem si v C++ doslova naklipal grid a nacet do nej tataz data ... tak sem srolovat asi tak 1000x rychlejs bez znatelny zateze CPU. Toz asi sem pri tom klipani jako neprogramator zapomel neco zmrvit nebo nevim ...
MS se snažil přepsat Windows do .NETu? Fakt? Já si všiml jen toho, že ve Vistě byl v nějaké fázi explorer.exe přepsaný do .NETu, a nakonec zůstali u C++. Ale možná máte lepší zdroj informací.
Právě jsem si založil projekt, natáhnul GridView na form a ve wizardu vybral tabulku z DB. Trvalo to cca půl minuty včetně spuštění VS, a napsal jsem u toho nula řádků kódu. Žádné vytížení CPU v task manageru nepozoruji. Zjevně tak nízké, že bych ho musel měřit perfmonem. Ale pokud chcete napsat v C++ form s datagridem, který vytíží CPU klidně na 100%, tak bych to jistě zvládnul :D. Jinými slovy to co jste viděl není o výkonu datagridu v .NETu, ale o nějaké prasárně autora kódu.
Ještě si pamatuji, kdy budoucnost podle vás bylo Singularity. Teď je to zmršené C++ s ořezaným .NETem. Za deset let to třeba bude i ISO C++ a MS konečně zvládne něco udělat pořádně :-)
Ano, právě kompatibilita s Win32 je problém. Managed kernel má samozřejmě nějaký overhead, ale je to do značné míry vyvážené tím, že neexistuje context switch mezi procesy. Bohužel při běhu Win32 kódu context switche zůstávají, takže to ohledně výkonu není dobré. To by asi tolik netrápilo uživatele Wordu, ale na DB nebo aplikačním serveru by to nebylo dobré.
Dalším problémem je rozumná implementace unmanaged Win32 nad managed kernelem. Aby to celé přineslo kýžený výsledek, tedy dramaticky zvýšenou stabilitu a bezpečnost, bude potřeba psát aplikace v jiném prostředí. Windows Runtime je podle mě krok přesně tímhle směrem - k bezešvé integraci managed a unmanaged kódu.
Zkurvenej antispam...
http://pastebin.com/download.php?i=RAc5Jbvv
V pythonu vetsinou nedeklarujete typ promenne, coz vede k runtime chybam, ktere by se daly odhalit compiletime. A neni to jen o promennych. Zrovna toto muze zprehlednit kod a urcite to zlepsi jeho udrzovatelnost. (Coz zase ovlivni riziko padu.)
U ostatnich bodu s vami souhlasim, ze C++ neni lepsi - je totiz stejne dobre.
Tak ve své podstatě to ani není potřeba, protože to ohlídá kompilátor. Narážel jsem na to, že u Pythonu tohle nejde udělat a nikdo to před spuštěním neohlídá, protože až do použití té funkce není jasné, co vlastně očekává (kromě dokumentace samozřejmě, ale tu budou nějaké automatické nástroje těžko studovat).
C++ stejně dobře (např.) čitelné jako Python? To je tedy opravdu odvážné tvrzení. Typová kontrola v době kompilace pomáhá, ale bez pořádného typového systému (alespoň na úrovni třeba Haskellu) se na ni moc spoléhat nedá. Objektově orientovaný assembler by nevyřešil v podstatě jediný podobný problém, který jsem v Pythonu na rozsáhlých projektech narazil a to je použití symbolické konstanty (číslo) tam, kam patřila jiná sada konstant.
Takže ano, teoreticky je C++ v tomto ve výhodě, ale za ty problémy to podle mě nestojí.
On je tady ještě jeden podstatný faktor. Když člověk dělá víc jeden jazyk a jeho knihovny, může mít problém přepnout na něco jinýho. Když skočí na třeba z PHP na C, tak cykly se zapisují stejně, podmínky se zapisují stejně,... Ale najednou přibudou třeba typy dat, je to pár řádků navíc, alepůsobí to tak nějak rušivě... Javař může mít probléy s tím, že zapomíná jince explicitně volat destruktory... A podstatně se liší i knihovny, který jspu k dispozici. Člověk tápe, jaký soubor přilinkovat a jak se ten objekt / atribut / metoda / funkce / konstanta jmenuje...
Programovací jazyk je nástroj. Pokud ovládám jazyk, ve kterým dokážu efektivně a uspokojivě vyřešit zadání, dá se použít. A je to lepší, než použít sice vhodnější a efektivnější jazyk, který se ale musím napřed naučit a projektový čas běží...
A to je argument pro co? Rikate tedy, ze pokud bych umel pouze visual basic, mam vse psat ve visual basicu? Nebo pokud budu umet jen assembler, mam vse psat v assembleru, abych neztracel cas ucenim se noveho jazyka?
Takovato logika je zcestna, a velmi silne zavani povestnym "Kdyz jediny nastroj co mam, je kladivo, vsechno zacne brzy vypadat jako hrebik".
Z meho pohledu je chyba v uvazovani tam, kde se predpoklada ze clovek umi jeden jazyk perfektne, a naucit se jine mu bude trvat neskutecne dlouho.
Nejenze to neni pravda (python jsem byl schopen obstojne pouzivat po cca tydnu "uceni", a s kazdym novym jazykem, ktery jsem se naucil, mi zvladnuti dalsiho trvalo kratsi dobu), ale hlavne: jakykoliv programator, ktery neumi alespon 2 (ruzne*) jazyky, je u me mrtvy programator. Pripadne jakykoliv vyvojarsky team, ktery ve svych lidech nema znalosti alespon 4 (ruznych*) jazyku, je odsouzen do propadliste dejin.
Tj. dle meho nazoru problem "musime se naucit novy jazyk" neexistuje, protoze kompetentni vyvojar umi vicero jazyku (dobra kombinace by byla treba C/C++, Java, Python, Javascript, Scala), a pouzije ten, ktery je pro dany problem nejvhodnejsi.
* ruzne - tim myslim skutecne vyrazne odlisne, ne veci jako (C++ a C), (ruby a python), (Java a C#) nebo (C++ a PHP)
To je jenom pozstřeh z praxe, často se setkám s tím, že někdo umí (většinou mizerně) jeden jazyk a špiní ostatní jazyky, aby se nemusel nic dalšího učit.
Jde o to, že pokud mám možnost volby (není to např. starý projekt nebo rozhodnutí managementu) a umím Javu, nemusím týden zkoumat C#. Prostě z každé skupiny jazyků stačí pro vlastní potřebu dobře zvládnout jeden (skriptovací, interpretovaný OOP, web script...) a když člověk něco potřebuje, tak to prostě nativně použije.
Ale to celoživotní vzdělávání beru, čím víc jazyků zvládám, tím větší odstup od problému mám a tím líp se hledá efektivní řešení. A nesvazuju obecný řešení s jazykem nebo platformou.
Zrovna píšu takovou jednoduchou Java EE aplikaci. Funkcionalita je daná, vychází z požadavků – pojďme se tedy podívat na technologie: např. to, co vyřeším pomocí jednoho SQL nebo XPath dotazu, bych psal v „čistém Céčku“ na kolik logických řádků? Skutečně by to bylo méně kódu a byl by přehlednější? Konverzi a filtrování dokumentů bych měl dělat místo v XSLT taky v C? Opravdu by to bylo efektivnější a čitelnější? Měl bych raději použít „plain text“ a souborový systém a napsat si nad tím na zelené louce „pár funkcí v Céčku“, místo abych použil relační databázi, kterou již napsal, odladil a otestoval někdo jiný? Nepřijde mi to jako dobrý nápad – takový software by byl mnohem dražší, vývoj by trval déle a údržba a rozvoj by byly obtížnější.
a nejde jen o to napsat to v C, ale proc tam jsou obludnosti
jako: sql, xpath, xslt.
ja si lepsi svet predstavuji jako misto, kde neni sql databaze.
misto toho jsou ruzne filesystemy pro ruzne pouziti (male/velke soubory, read-only, komprimovane....)
misto xml muze byt zase filesystem s textovymi, obrazkovymi, hudebnimi soubory.
staci takovy filesystem zatarovat a mate v nem totez co v xml.
takze filesystem je prirozena reprezentace stromu, vsecko ostatni lze udelat pomoci toho.
Hmm, a ktery filesystem ti v transakci secte hodnoty v souborech, nastavi jim prizkank zpracovano a vlozi vysledek do jineho souboru? Proste SQL ma sve pouziti, a je rozsirena prave pro to, ze dovoluje oprostit se od popisu jak se k vyslednemu fungovani dostat. Jen popises co ma byt vysledkem. Diky tomu je mnoho programu citelnejsich a snadneji spravovatelnych, polovina jejich funkcionality je totiz schovana ve fungovani SQL serveru. Z tohoto pohledu maji vyrazne mene logickych radek nez bez SQL.
Všechno nejde udělat pomocí stromu. Co takhle DAG, nebo nějaký úplně obecný graf? A jinde je zase strom zbytečně obecný. Relace je tabulka a cpát na ni strom je imho zbytečné. Proč napasovávat SQL (a relační databáze obecně) na stromy, když ty stromy budou stejně degenerované (alespoň z vnějšího pohledu)?
Mimochodem co indexy? Filesystém zaindexuje podle primárního klíče (název souboru), ale co ty další? Pokud přidám další pomocné soubory nemám nakonec zase implementaci relační databáze?
A k tomu xml : Jak bude vypadat ten soubor, které ty obrázkové, textové a hudební soubory složí dohromady? Takhle přece vypadají *.odt a podobně. Je to zip s hromadou souborů a jedním xml, které říka jak je to spojené dokupy.
Doc není proprietální filesystém v souboru. Doc je memorydump (nebo hodně jednoduchá serializace) COM objektů z wordu. KISS princip dotažený do dokonalosti :) Jen to kapku drhne.
A odt je plný xml, takže by měl být v kontextu tohohle článku špatný, ne? A Java je přece zlo taky. A v tom jaru se to zlé xml taky najde.
> vsecko ostatni lze udelat pomoci toho.
Však ono to tak je také uděláno, drtivá většina SQL strojů stojí a padá na API filesystému a pokud aplikace potřebuje velké data, tak se nedávají do SQL, ale normálně se uloží standardně do filesystému a do SQL se dávají jenom odkazy na ně.
Taktéž není třeba všude instalovat "velké" SQL servery. Existují i malé SQL věci, kde stačí k aplikaci přidat 2 ks DLL/SO a aplikace může využívat vymoženosti SQL.
Dobrý databázový systém nemá s velkými soubory problém, klidně tam můžeš naprat obrovské BLOBy – databáze si to stejně uloží do separátních souborů, ale ty od toho abstrahuješ – je ti jedno, jestli je to několika-prvkové pole bajtů nebo gigový ISO obraz, s obojím můžeš pracovat pomocí stejného API.
Ten důvod proč dávat velké soubory rovnou na FS než do databáze je spíš ten, že z databáze ty data musí obvykle protékat přes tvoji aplikaci a zbytečně ji to zatěžuje – zatímco z FS to můžeš třeba nasdílet nějakým jednoduchým protokolem po síti nebo jen dát příkaz HTTP serveru, aby servíroval určitý soubor z disku (tzn. data nemusí fyzicky téct přes tvoji aplikaci, ale přesto si u nich můžeš řídit uživatelská oprávnění nebo logovat přístupy).
Někde svoje místo databáze mají, ale je potřeba na to jít s rozmyslem. Boeing 747 taky převeze skoro všechno, ale asi bych s ním neletěl 10km do stavebnin pro pět pytlů cementu. A jsou jedinci schopní zatěžovat systém během nějaké SQL databáze, aby na statické weboce vygenerovali menu.
XML bych nezatracoval. Je čitelný / editovatelný i ručně a reprezentuje strom. Existuje lepší textový formát třeba pro hierarchický dokument (nadpisy několika úrovní,...),? Wiky, Texy,... jsou proprietální a nestandardní formáty. Je potřeba v čitelné formě uložit vektorovou grafiku? Bod má dvě souřadnice, kruh tři, úsečka čtyři... V CSV se to v textové formě ukládá blbě, tak budou generovat řádky s příkazem a parametry a psát na to parser, když můžou použít hotovou implementaci DOM a ušetřit si práci? Tak tomu, pánové, říkám masochismus...
"zatěžovat systém během nějaké SQL databáze" - nezlobte se, ale to je naprosty nesmysl. Pokud k DB nepristupuji, tak zatezuje procesor bud uplne minimalne, nebo dokonce vubec.
Prirovnani k 747 je uplne mimo. Kdyz mam nejaky web, a zvysi se mi skokove navstevnost 1000x, vetsina SQL DB to v pohode zvladne, ale nejake ad-hoc reseni se pravdepodobne uvari. Klicove slovo: "skalovatelnost"
XML bych zatracoval velmi silne. Ano, existuje - mnohokrat jednodussi na parsovani, neskutecne vic rucne citelny a nekolikanasobne mensi co se velikosti vysledneho souboru tyce - JSON.
Nicmene prestoze bych XML zatracoval, uznavam, ze diky svemu rozsireni jako defacto standard je to nezbytne zlo. A lepsi pouzit XML nez nejaky svuj "suckless" format.
Myslim ze tady je zrejme, ze "ze zatezovat system behem SQL databaze" bylo mysleno tak, ze staticke menu ke staticke strance je generovano SQL dotazem do databaze (v horsim pripade zabalenym do nejakeho ORM, takze to nacteni menu z te databaze vytahne i obsach vsech odkazovanych stranek, ktery nasledne zahodi).
> v horsim pripade zabalenym do nejakeho ORM
V čem nepoužití ORM (nebo jiné abstrakce) zjednoduší kód? (tak aby měl méně logických řádek, o to nám přeci jde, ne?) V té své aplikaci jsem tentokrát žádné ORM nepoužil – chtěl jsem změnu, trochu se potrénovat a víc si užít SQL :-) mít blíž k databázi a část implementovat pomocí DB procedur. To se povedlo a s výsledkem jsem spokojený, nicméně realita je taková, že jsem musel napsat o něco víc kódu, než kdybych použil ORM – tam by totiž stačilo pár anotací a o zbytek by se postaralo JPA. Není to nějak drastické (zvlášť u takhle malé aplikace), nicméně ta tendence je jasná: nepoužití ORM → více ručně psaného kódu.
> takze to nacteni menu z te databaze vytahne i obsach vsech odkazovanych stranek, ktery nasledne zahodi
Obyčejný FUD, možná to tak v nějakých parodiích na ORM je, ale v zásadě by neměl být problém si vytáhnout z databáze jen určitá data. V JPA můžeš napsat dotaz tak, aby výsledkem byly instance nějakého úplně jiného objektu (který ani nemáš namapovaný na databázi). Vtip je v tom, že je to silně typované – lezou z toho objekty, ne nějaké beztypové pole, u kterého nevíš, co uvnitř bude a musíš to přetypovávat a doufat.
A kdyby nic jiného: můžeš použít klasický SQL dotaz, i když ve zbytku aplikace používáš ORM.
Ano dobre (a spravne pouzite) ORM snizuje pocet logickych radek (zvysuje citelnost) aniz by se vyzname zvysila narocnost. Jenze to spravne pouziti ORM casto predpoklada, ze clovek, ktery ho pouziva, vi (zhruba) co to ORM vykona, kdyz neco napise. Ostatne to je i pripad SQL, je skvele tim, ze se nemusite zabyvat jak presne dojde SQL server k vysledku, ale musite priblizne vedet kde pouzije indexy, kdy udela sekvenci scan, a tak podobne, jinak se vam muze stat, ze pouzijete neco se spotrebou boeingu 747 na cestu do trafiky pred barak. Proste jak psal 'Petr M' - nekde SQL a ORM opodstatneni maji, a nekde ne.
> ale proc tam jsou obludnosti jako: sql, xpath
Protože aplikace si potřebuje držet stav – data (nebudu říkat záznamy nebo objekty, protože to už je implementační detail, abstrahujme od toho) a s těmi daty potřebuji něco dělat. A většinou ale ne se všemi daty, ale s nějak definovanou podmnožinou. Buď si na to napíšu SQL dotaz s WHERE podmínkou nebo třeba XPath dotaz, který vyfiltruje elementy na základě jejich atributů a dalších vlastností… a nebo bych mohl pokaždé v Céčku iterovat přes pole všech dat a pomocí několika IFů z nich vytahovat požadované položky.
Jak relační databáze, tak XML databáze podporují indexy a tohle hledání/filtrování je efektivní – většinou nemusím dělat full table scan.
Plus, jak už tady padlo, transakce, agregační funkce atd. – tohle všechno mám při použití databáze „zadarmo“ – nemusím to programovat, nemusím to testovat, prostě to funguje. Prostě dám BEGIN a COMMIT a nemusím řešit, v jakém pořadí mám přejmenovávat a přepisovat soubory a dělat nějaké další vylomeniny, aby byl systém po případném výpadku v alespoň trochu konzistentním stavu. A když narazím na něco, co se mi nelíbí, dám ROLLBACK a vše je zase v původním stavu – nemusel jsem si kvůli tomu někam poznamenávat všechny provedené kroky a návod, jak je vrátit zpátky – to za mě dělá ta „obludnost“ relační databáze. Funkce jako sum, min, max, avg… mi spočítají výsledek, aniž bych ta data musel natahovat do mé aplikace – který souborový systém tohle umí? Leda tak spočítat počty souborů nebo orientačně obsazené místo, ale tím to hasne – obsahu souborů nerozumí a to už bych musel řešit ručně v aplikaci já.
> ale proc tam jsou obludnosti jako: … xslt
XSLT mi pomáhá např. zjednodušovat data – není potřeba se na to dívat jako na nějaké XML, text s ostrými závorkami, ten tam ani nikde být nemusí – prostě je to strom tvořený uzly různých typů a ten já chci převést na jiný strom s podobnou strukturou, ale zachovat jen některé uzly a jiné trochu upravit nebo nahradit něčím jiným.
> misto toho jsou ruzne filesystemy pro ruzne pouziti (male/velke soubory, read-only, komprimovane....)
Souborový systém je dobré lokální API, docela fandím různým FUSE souborovým systémům, která zpřístupňují data (třeba i z SQL databáze nebo XML) formou FS a uživatel může abstrahovat od toho, jak jsou data uložena a pracuje s nimi vždy stejně jako se soubory. Ale není to všemocné – např. nějaké dotazování se tam dělá dost špatně (leda přes nějaké virtuální adresáře). Ale jako primární (nevirtuální) úložiště toho FS nabízí hodně málo – právě proto se nad ním používají buď databáze nebo nějaké chytře navržené formáty souborů (indexy, metadata…).
> misto xml muze byt zase filesystem s textovymi, obrazkovymi, hudebnimi soubory. staci takovy filesystem zatarovat a mate v nem totez co v xml.
Pokud napíšeš SAX parser, který umí tu adresářovou strukturu nebo .tar načíst, tak máš v podstatě pravdu. V té své aplikaci jsem si jen tak z legrace přidal ukládání metadat o souborech do jejich rozšířených atributů. Je to pár řádků (doslova) a vliv na výkon není měřitelný, takže proč ne :-) Takže mám (meta)data jak v relační databázi, tak na souborovém systému a můžu k nim přistupovat z obou míst. Ale schválně, kde je to jednodušší a efektivnější? Radši napíšu SQL nebo XPath, než abych psal cyklus v BASHi a v něm parsoval/grepoval výstup příkazu getfattr
a v nějakém IFu rozhodoval, zda soubor na výstup zařadit nebo ne. Nebo mi snad FS nabízí nějaké API, které by mi umožnilo vyhledat soubory, které mají např. atribut aaa = 123 a zároveň atribut bbb > 5 ? Až něco takového bude existovat, velice rád to budu pro jednodušší aplikace používat. Do té doby zůstávám u „obludností“ typu SQL a XPath.
BTW: úplně nejlepší by bylo SQL/XPath rozhraní k souborovému systému, které by umožnilo pomocí standardního jazyka provádět dotazy nad soubory a adresáři :-)
> takze filesystem je prirozena reprezentace stromu, vsecko ostatni lze udelat pomoci toho.
Ono to lze i bez FS – některé DBMS můžou pracovat nejen nad FS, ale i nad blokovým zařízením, např. LVM oddílem. Ovšem to „lze udělat“ znamená, že někdo musí napsat spoustu funkcí/metod obecně kódu – a většinou nemám důvod toto implementovat znova a znova ve svém aplikaci, ale použiji nějakou databázi, kde už je to hotové.
ja jsem velky zastance vsecho jako fs.
ja bych naopak zase zminil sqlfs, xmlfs.
http://www.slideshare.net/jserv/plan-9-not-only-a-better-unix
Myšlenky to jsou zajímavé, ale někdy mi ta snaha napasovat všechno na soubory přijde trochu moc kostrbatá – viz třeba příklad:
% cat /net/tcp/clone/ct1 44 % cd /net/tcp/44 % echo connect 128.2.194.80!79 > ct1 % echo ping > data % cat data pong
Trochu mi to připomíná současnou situaci kolem RESTu – tam je taky často vidět až křečovitá snaha udělat ze všeho „resources“ až těm lidem někdy uniká, že podstata té řešení úlohy je ve skutečnosti procedurální. Ano, i procedura se dá volat přes CRUD operace, ale není to ono…
No myšlenka je to dobrá, když může fungovat down sizing v automobilovém průmyslu, proč by něco podobného nemohlo fungovat na poli software a OS? Otázka ovšem je, zda o to někdo vůbec v dnešní době stojí a zda to spíš není kontraproduktivní. Přeci jen, je rok 2013-14 a vracet se o 30 let zpátky asi moc lidí chtít nebude.
Berte to pozitivně.
Mám rád minimalismus a program má mít jen tolik řádek, kolik je potřeba. Pokud se zdá, že nějaká vlastnost nepatří do jádra programu, tak ji lze zavést jako modul přes univerzální rozhraní.
Tento projekt jde ale mnohem dál a je mnohem extrémnější. Ale to nevadí - prostě jen přitáhne odpovídající "úchyláky" a ti nebudou prudit jinde.
Jednou možná budeme rádi za to, že existuje jejich minimalistický operační systém, který bude natolik bezpečný, že v něm bude možné něco dělat bez jistoty, že se nám někdo dívá přes rameno (CIA,FBI,BIS,.................).
Přestože některé myšlenky jsou pozitivní, jako například že aplikace má dělat jednu věc a to pořádně, přesto je to nesmysl hned v prvním odstavci a to příklon k C a statickému linkování. To proto že práce v C naopak nutně zvyšuje požadavek na počet řádků kódu, například při automatickém uvolňování stringů a paměti obecně nebo práce s chybami a proto aby to potřeba nebylo se vymyslelo C++. Je to evidentně nezkušenost komunity celkově. Také je nutno zmínit že v Linuxu se prakticky nedá rozumně vyrobit pouze staticky linkovaná binární aplikace, pokud tato nebyla slinkována přímo pro konkrétní instalaci systému.
> Také je nutno zmínit že v Linuxu se prakticky nedá rozumně vyrobit pouze staticky linkovaná binární aplikace, pokud tato nebyla slinkována přímo pro konkrétní instalaci systému.
To jim myslím vůbec nevadí, když si uvědomím, že jejich výtvory mají konfiguraci zapsanou ve zdrojáku a je je třeba při každé změně překompilovat.
Tohle mě v tom článku taky zaujalo. Na jednu stranu je fajn ten důraz na otevřený zdrojový kód a taky že to trénuje uživatele v tom, že si program může upravit, může změnit kus kódu a hned vidět výsledek (když umí měnit konfiguraci, je jen krůček k tomu, aby změnil o pár řádků dál chování programu k obrazu svému). Ale na druhou stranu tohle udržovat musí být fakt peklo. Už jen to, že takový program nelze nainstalovat systémově (a jen nechat každého uživatele načíst jiný konfigurák), ale i případná aktualizace – až vyjde nová verze programu, musím zkoumat, co jsem kde změnil v rámci konfigurace, to si nepřepsat, zbytek aktualizovat a modlit se, že to půjde zkompilovat.
V jednej veci máte pravdu. Je problém naištalovať jeden program pre viac použítaľov na jednom počítači cez balíčkovací systém. Presnejšie povedané, neviem ako to majú iné distribúcie, ale na gentoo je možnosť si uložiť konfiguráciu do /etc/portage/saveconfig a on to pri aktualizácii, alebo prekompilácii balíčku použije uloženú konfiguráciu. Čiže len jedna konfigurácia. Keďže dnes zväčša používa jeden počítač jeden človek, až tak veľký problém to nie je. Inak si musí každý sám urobiť vlastnú kompiláciu do svojho ~/bin adresára.
Ohľadom konfigurácie. Neupravujú sa priamo zdrojové súbory, ale súbor config.h, ktorý je klasický hlavičkový súbor c-čkového programu a ten definuje čo sa v kóde ako má použiť. Myslím, si že konfigurácia v jazyku v akom je napísaná aplikácia je to najvýkonnejšie čo môže byť. (pre kódera je to aj veľmi prehľadné, pre používateľa, čo ten jazyk nepozná to tak nemusí byť.
Ak budete aktualizovať tak stačí dať diff na config.h a tam toho až tak veľa nebude. (aj konfiguračné súbory sa možu rozvíjať a meniť.)
Používam pár programov, čo sa takýmto spôsobom konfigurujú a som celkom spokojný. (napr. zathura, xmonad, st)
Nevim co tu nekteri prskaji, zvlast kdyz se dotknou jejich oblibeneho jazyka/paradigmatu/desktopu/politicke orientace a buhvi ceho jeste. Uplne stejny fanatismus jaky je vycitan autorum projektu.
Jsem napr. velmi spokojenym uzivatelem dmenu, ktery je presne takovym typem programu, ktery vystihuje proc jsem tak rad utekl od Win k *nixovym systemum . Mala utilitka, ktera dela perfektne jednu vec, je maximalne jednoducha a je univerzalne pouzitelna - staci ji nacpat na standardni vstup prakticky cokoliv odkudkoliv. Nezavadi zadnou vlastni syntaxi, staci prosty textovy obsah. Navic je pekelne rychla a zere minimum prostredku.
Pouzival jsem i wmii, ktere melo nektere genialni koncepty (stacking mode, dynamic tagging, genericke ovladani pres plan9 fs) dotazene skoro k dokonalosti, ale bohuzel se jim projekt rozpadl pod rukama. Nedokazali udrzet pod kontrolou mnozstvi SLOC a kod bobtnal, oprava jednoho bugu pridala x-dalsich a celkove se stal neudrzovatelnym, resp. ho odepsali a soustredi se na dwm.
Jako nahradu wmii prijalo mnoho uzivatelu projekt i3, ktery ma velmi podobne ovladani a spravu oken, ale konfiguace je sice pres textak, ale s limitovanou sadou pravidel.
Musim souhlasit s autory, ze vetsina vyvoje jde spis cestou efektivnosti, nikoli efektivity. Jak moc se zvysila pouzitelnost prostredi typu KDE nebo GNOME od jejich rannejsich verzi ? Proc se resi blbinky typu vzhled prostredi , graficke efekty nebo obrazek na pozadi ktery je stejne vetsinu casu prekryty ? Ja prostredi chapu jen jako ramec, ve kterem bezi aplikace se kterymi realne pracuju. Proc by melo zabirat vice nez nezbytne mnozstvi systemovych prostredku ? Ja uz bych si nedokazal predstavit praci bez tiling manageru typu i3 nebo xmonad, ktere zabiraji v RAM radove jednotky MB, < 1% CPU, bleskove startuji a reaguji na povely(zpravy) a lze je prizpusobit vlastnim potrebam daleko za hranice moznosti KDE nebo GNOME (resp. kwinu, metacity/mutteru). A hlavne uplne odpada nutnost presouvat, zarovnavat, zvetsovat/zmensovat okna - naprosto zbytecne operace, ktere jenom zdrzuji. Navic kompletne ovladatelne jen pomoci klavesnice, ktere je oproti mysi rychlejsi, presnejsi a nektere operace proste nelze provest nebo jen omezene a strasne krkolomne pomoci gest.
Myslenka projektu Suckless mi je hodne sympaticka, ale nelze ji brat jako dogma. Stejne jako u jakychkoli jinych myslenkovych proudu si vybrat jen zajimave idey a zaroven se pri tom vyhnout ideologii, ktera jednak limituje ale hlavne vzdycky smrdi ...
Preferovany objem pozlatka a chut obetovat pre DE nejaky ten MB navyse za sadu featur, z ktorych potrebujem/pouzivam len niektore je samozrejme vecou osobnych preferencii a tiez ucelu, na ktory je pocitac pouzivany.
>>a lze je prizpusobit vlastnim potrebam daleko za hranice moznosti KDE nebo GNOME (resp. kwinu, metacity/mutteru)
to je hodne odvazne tvrdenie... tiling manazery nepoznam, ale skusim napisat, ake vychytavky kwinu pouzivam:
presun aplikacneho menu do samostatneho widgetu, ktory ma autohide (toto je mozno vec Plasmy, neviem)
standardny start niektorych aplikacii (napr. remote desktopu) bez titlebaru a borderov
automaticke otvaranie novych instancii aplikacie do tabov (file manager a terminal)
hot corners
pre referenciu, vyklikavacie nastavenia a pouzivane dostupne atributy su popisane tu:
http://userbase.kde.org/KWin_Rules
http://userbase.kde.org/KWin_Rules_Window_Attributes
no a to su len klikacky, komu nestaci, moze si zacat scriptovat
Pokud napisete "tiling manazery nepoznam", cely zbytek vaseho prispevku je zbytecny.
Netvrdim, ze tiling managery jsou jedine spravne, a xmonad je jejich kral (i kdyz si to myslim :). Ani netvrtim ze KWin je spatny nebo nejak menecenny. Verim, ze kazdy clovek ma svuj zpusob prace s pocitacem, a pokud je to pro Vas KWin, fajn.
Tvrdim, ze byste nemel argumenovat, kdyz nevite o cem mluvite.
A abych jen netvrdil, tak zde je vysvetleni, proc si treba ja myslim, ze konkretne XMonad je mozne prizpusobit vlastnim potrebam daleko za hranice moznosti KDE/GNOME: jako konfiguraci ma normalni zdrojak v haskellu, takze pokud umite haskell (ano, trochu omezujici podminka, ale nikdo netvrdi ze XMonad je pro kazdeho), je z principu mozne ho prizpusobit naprosto libovolne. Skutecne neni zadny limit. Dokonce si myslim, ze kdyby se nekdo hodne snazil, dokaze v XMonadu naprogramovat prostredi ktere bude temer nerozeznatelne od KDE :)
Nechcel som opakovat chybu predchodcu a teda som si pred svojou povodnou reakciou najskor pozrel, co dokaze i3 http://www.youtube.com/watch?v=QnYN2CTb1hM , ale len na zaklade toho by som si este nedovolil napisat, ze tiling manazery "poznam".
Pojdem si pozriet aj ten XMonad, aby som sa cosi poducil. Kludne ste mnohli tiez uviest, ake vychytavky XMonadu pouzivate pre inspiraciu.
Este poznamka, Haskell (XMonad) aj Javascript(scripty pre Kwin) su Turing-kompletne a teda aj moznostami ekvivalentne. Kde tam vidite vacsi priestor pre prisposobovanie?
Inac pre KWin niekto napisal script na tiling http://opendesktop.org/content/show.php?content=161151 , ale na dvoch monitoroch s rozlicnym rozlisenim moc dobre nefunguje :)
Ah.. zda se ze mi vypadla nejpodstatnejsi informace - XMonad JE napsany v haskellu, a pri zmene "konfiguracniho zdrojaku" se na jeden prikaz (defaultne myslim Win+Q) prekompiluje a pouzije v bezicim xmonadu.
Takze ten rozdil je, ze muzete hrabat i do vnitrnosti xmonadu.
Jinak jake "vychytavky v XMonadu pouzivam" je velmi zavadejici dotaz - zaprve vetsinu veci co pouzivam nepovazuji za "vychytavky" ale za celkem primitivni veci souvisejisi s tim, abych mel veci tak jak chci (lauouty ruznych ploch, prepinani oken, zmeny deleni oken, a k tomu vsemu patricne klavesove zkratky ktere mi prijdou vhodne). A zadruhe mi fungovani standardniho XMonadu vyhovuje tak, ze veci, ktere bych oznacil za "vychytavky" mam minimum, nebo mozna asi zadne.
Muj argument tedy nebyl o tom, jake "vychytavky" (okna mapovane na dvacetisten!, prepinani pomoci telepatie!! 1000 slonu!!!) zde mam, ale spise o tom, ze diky konfiguracnimu souboru, ktery se zkompiluje a stane soucasti beziciho xmonadu napsaneho ve stejnem jazyce jako konfigurak, mam moznost tyto veci udelat (az na ty slony asi :) - takze jediny duvod, proc to asi nikdo neudelal, je ze je to blbost :).
suckless jsem si všiml už před pár lety a jsem rád, že se objevil článek na rootu, díky :-)
(doufám, že nezůstane bez povšimnutí i technologie s jakou vyrábějí obsah webu ;-)
... přesto, že je mi suckless projekt sympatický, tak jdu jinou cestou a denně používám technologie, kterých by se Oni nedotkli ani násadou od koštěte :-D
Vidím to stejně. Mám rád funkční řešení a produktivitu práce.
Představa, že píšu nějaký dokument, zavřu textový editor, otevřu header file vkládače tabulek, vepíšu do #define počet řádků a sloupců, pak to zbuilduju, na command line napíšu cestu k dokumentu a číslo řádku, za který to chci vložit, pak otevřu dokument v CLI editoru tabulky se souřadnicemi buňky v parametru a vyplním její obsah, abych to pak mohl otevřít znovu v pro další buňku a pokračovat dál, je přímo odporná. To už raděj velký kancelářský balík :)