Názory k článku 602SQL Server: historie velkého produktu vyvinutého v malém týmu

Pravda, ohledně řešení kvalit kódu, námitku beru. To je fakt.

Obzvláště v souvislosti s ANSI C (a třeba i lepší typová kontrola, ...). To teprve začínalo a v počátcích 90 bylo vidět i kódy v původním zápisu K&R. Člověk byl rád, že se přeložilo (často zápis mix původní K&R, něco mezi tím i ANSI C dohromady) a fungovalo (ideálně pod více překladači, pro jistotu). Natož aby se zabýval kvalitou kódu.

Suhlas. Na vyske v 1. rocniku (90/91) stale "letel" Pascal a dokonca aj pomocny program k cipu, ktory som navrhoval ako diplomovku som pisal v 1995 v Pascale. Az ked mi diplomovy veduci povedal, ze ak chcem byt "cool" tak to mam napisat v C tak som sa za tyzden naucil zaklady C, prepisal som to a multiplatformne skompiloval pod Windows aj pod Unixom.

Já tedy v roce 1995 používal C docela běžně. A Pascal jsem používal i později, protože Delphi.

Napsal jsem to blbě, nejasně. Měl jsem na mysli, že v těch letech už se člověk mohl spolehnout na to, co se cca 15 let před tím zavedlo jako C++ novinka.

Takže class byl class, fungovalo základní dědění (virtuální dědění byl problém) a virtuální funkce (libovolný počet) nafoukla data o pouhý jeden pointer (+ jednu společnou tabulku na class) a fungovaly. Základní overloaded operátory fungovaly /dostatečné pro iterátory/ (dokud ze nezačaly vnořovat či řetězit, to občas selhalo kdy který použít). To vše běhalo prakticky všude (co si pamatuji).

Ne, že se začaly fungovat C++ novinky 90 let (jako template, ...).

P.S.: Bavím se o dos/win x86. Neberu v úvahu ani GNU / Linux (potažmo gcc). Linux v tu dobu stále začínal. Někdy od 93-94 se už dal používat i na mírně vážnější věci (Slackware to jistil, díky díky za něj), ale stále to bylo v plenkách.

Zase blbě nepřesně. Iterátorem myslím akorát tak primitivní upravený offset do pole [] a případně ++ resp. += pro odpovídající index. Ne template iterátory, jak si je člověk představí dnes.

Zrovna dnes jsem měl doma instalatéra. Sice netrval na tom, že si bude sám vyrábět vodovoní baterii, ale měl poměrně divně vypadající nástroj. Povoloval a utahoval tím nějaké šrouby. Byly to tři trubky spojené na dvou místech kloubem. Prý mu to vyrobil kamarád a on tím dokáže pohodlně odšroubovat/přiš­roubovat baterii bez ohledu na to, kolik je kolem ní místa. Laicky mi to přišlo jako kardan, kde na jednom krátkém konci je násuvný bit a na druhém rokojeť.

https://cs.wikipedia.org/wiki/Kardan%C5%AFv_z%C3%A1v%C4%9Bs

A o tom to podle mne je. Ne o tom psát si vlastní kompresní algoritmus, ale o tom sám pro sebe si napsat lepší nástroje. Já těhle jednoúčelovek mám docela dost. Výhoda je, že přesně vím, co to dělá a co ne. Vlastní XML parser jsem nepsal, ale mám třebas vlastní parser na soubor "hosts", který mi ho umí i přepisovat. Jasně, mohl bych implementovat něco jako No-IP, ale zrovna tady mi to přišlo snadnější si to udělat po svém, bez internetu a bez třetí strany.

Akorát zrovna SQL je na parsování dost komplikovaný jazyk – zajímalo by mne, zda třeba Oracle SQL se všemi jeho rozšířeními vůbec jde popsat nějakým formálním zápisem.

Pokud jde o rozsireni, tak treba takovy MySQL je na tom mnohem hure, presto ze je mladsi. U Oracle jde predevsim o zpetnou kompatibilitu. Vsechna klicova slova je stale mozne pouzit jako udentifikatory. A s tim si zadny tool neporadi.
Napr.

select * from commit;
select * from T join join on (T.C = join.C)
select * from model model partition by C1 dimension by C2 ...

PS: udrzovat vlastni parser napsany v imperativnim jazyce je hard-core. I mala zmena gramatiky muze znamenat ze musite prepsat uplne vsechno. Pouziti deklarativniho generatoru usetri spoustu prace, problem nastane az kdyz narizite na limitty toho toolu.

Gramatika se da vytvorit. Bohuzel neni 100% kompatibilni s Oracle. Prave kvuli tomu, ze Oracle si nemuze dovolit rict, ze napr. slovo "MODEL" bude v dalsi verzi vyhrazene slovo a proto uz nadale nikdo nesmi vytvorit tabulku s timto jmenem. Tahle gramatika puvodne byla ISO SQL 92 a nakovec z toho vznikl parser Oracle PL/SQL:

https://github.com/ibre5041/plsql-parser

Oracle má vlastní parser už proto, že tam toho strašně moc záleží na metadatech. Jeden a ten samý text může znamenat něco jiného podle toho, co existuje za tabulky atd. Přidejte konstrukce, které fungují jen s "look ahead" o poměrně vysokém čísle. LL parser na to sice funguje poměrně slušně, ale občas mu prostě dech dojde.

Oblíbený příklad jsou tyhle tři selecty. Oracle první a třetí zpracuje, druhý ne. Překvapení je v tom, že druhý ne. Protože Oracle dovolí použít "inner" jako alias tabulky (viz 1) a zároveň je "inner" v "inner join" nepovinné (viz 3), tak by podle gramatiky mělo být i 2 zcela validní. No a není. Podle toho, jak to má která gramatika ošetřené, se prostě některý z těch 3 dotazů povede a zbytek ne. Ale přesně tak jak to má Oracle - 1 a 3 ano, 2 ne, se ta gramatika napsat nedá, tam už se holt musí vnutit nějaký IF na "pokud dvakrát inner tak..."

select * from dual inner inner join dual on inner.dummy = dual.dummy
select * from dual inner join dual on inner.dummy = dual.dummy
select * from dual inner2 join dual on inner2.dummy = dual.dummy

No a přihoďte fakt, že lze založit tabulku jménem "inner" a sloupcem "dummy", díky čemuž začne fungovat všechno tohle:

select * from inner join dual on inner.dummy = dual.dummy
select * from inner inner join dual on inner.dummy = dual.dummy
select * from inner inner inner join dual on inner.dummy = dual.dummy

A ještě jedna drobná věc: udržovat ručně napsaný parser není zdaleka tak pracné, jak si někteří lidé myslí. Pořád je to parser rozlišující terminály a neterminály atd. a dokud se nepřekopají základy gramatiky, tak se prakticky nic nepřepisuje, jen se dopíšou nové věci. Úprava takového parseru zkrátka není řádově složitější než úprava gramatiky.

Tak tohle je bomba! Chtel bych mit cas na zkoumani podobnych blbosti. :)

I kdyz ted si uvedomuji, ze ho vlastne mam dost, jenom zkoumam jine blbosti.

Ten posledni sql dotaz s 3x inner mi pripomina vtip ze zakladni skoly, jestli znate vetu, kde je trikrat "ti" po sobe. "U riti ti tika budik."

Naprosto bez ironie dekuji za komentar, zlepsilo mi to naladu.

Kola na auto jsou vec, ktera je bud normalne k dostani od subdodavatelu a muzu je koupit hotove, nebo je pro novy model unikatni

Abych se vratil k Vasemu autu: loziska, srouby (mozna krome ojnicnich), matice, podlozky, tesneni, apod. - pokud cokoliv z toho nejaky inzenyr navrhne vyrabet, misto koupit hotove, tak bude za blbce.

Ty analogie jsou vylozene padle na hlavu. Ve stavebnictvi a v prumyslu jsou jednotlive dily vetsinou standardizovane a snadno zamenitelne. Staci specifikovat vlasnosti a dil najdes, to ve vyvoji software neplati.

Tam je to spis co vyrobek to unikat nebo atyp, ktery ma specificke pozadavky. Malokdy se stane, ze k tomu, co potrebujes, mas presne odpovidajici knihovnu nebo komponentu. Casto to dopada tak, ze do ctvercoveho prurezu potrebujes vlozit kruhovy dil, a musis vymyslet nejaky hack, jak to udelat. Uz mockrat se mi stalo, ze jsem v dobre vire pouzil nejakou knihovnu, abych s postupem casu zjistil, ze mi jeji logicka nevyhovuje nebo ze obsahuje koncepcni chyby. Vetsinou to pak skoncilo tim, ze jsem si celou funkcionalitu napsal od nuly a usetril tim spoustu casu, protoze nova knihovna zacala lip pasovat na me pozadavky.

Pro výměnu dat se používá standard XML (nebo aspoň JSON nebo nějaký jiný cool formát), komunikuje se opět nějakým standardizovaným protokolem (nejčastěji HTTP/HTTPS)

A jak toto prispiva do diskuze o znovupouzivani kodu a knihoven? Zaprve, myslel jsem, ze se tu nebavime na urovni integrace systemu, ale bezne tvorby programu, tj. implementace parseru, tridici algoritmu, apod.

Zadruhe, XML nebo JSON a protokol HTTP jsou jen formaty a protokol pro vymenu dat a neresi problem, ze aplikace ma data ve formatu ctverecku a protokol vyzaduje format kolecka.

Kdyz se tady bavime o parsovani SQL ve Winbase, tak by to podle dnesnich programatoru melo vypadalo tak, ze se vezme kod v SQL, posle se pres HTTPS nejake sluzbe vcetne gramatiky ve formatu JSON a ta ji vrati syntakticky strom opet v JSON, aby si to databaze mohla prevest do sve interni reprezentace.

Úplně stejně, jako je to v tom stavebnictví nebo automobilovém průmyslu.

Uz jsem to tu rikal, ve stavebnictvi i v automobilovem prumyslu jsou zavedene standardy, takze jednotlive dily jsou zamenitelne, protoze splnuji dane rozmery. Ve svete programovani tomu odpovida, ze dana knihovna implementuje jasne dane rozhrani nebo specifikaci, a to plati pro minimum veci.

Tak jsem napsal několik příkladů standardů, které se běžně používají, a pro které je málokdy dobrý nápad psát si vlastní knihovnu.

Sorry jako, ale tento myslenkovy pochod jsem z predchozich prispevku opravdu neodhalil...

A to XML, JSON, HTTP, to je co?

To jsou tri low-level priklady pro nez existuje specifikace. Jsou to spise vyjimky, kam bych treba jeste pridal JEE, ale z toho nejde delat zavery a stavu celeho odvetvi.

Uz z logiky veci (na rozdil od sveta fyzickych veci) nema prilis smysl mit vice vyrobcu jedne identicke (identicky chovajici se) veci. Ano, jsou vyjimky a jsou duvody, treba licencni, ale opet jich neni mnoho.

Řeč byla o knihovnách, původně v souvislosti s parsováním

Tak to su klidny. Protoze, pokud mame knihovny na parsovani XML a JSON a k tomu protokol HTTP, tak

doba, kdy bylo v IT vše atyp, je naštěstí už dávno pryč.

Nebrojím proti knihovnám a generátorům! Brojím proti názoru, že pokud na něco existuje nějaká knihovna nebo generátor, tak že je _vždy_ výhodnější je použít. Tak totiž vyzněl ten první příspěvek, na nějž jsem reagoval. "Na to existuje knihovna - měli ji použít. Na to existuje generátor, měli ho použít." To je prostě nesmysl. Nebudu ztrácet čas detailním studiem generátoru a vymýšlením, jak narovnat, co generátor naohýbal, když si to mohu napsat sám z jedné vody načisto. Nakonec napíšu méně kódu, navíc přehlednějšího a jsem s tím hotov rychleji, než s generátorem. Podobnou zkušenost mám (a zdaleka nejsem sám!) třeba s LaTeXem - přiohýbání nějakého makra dá často tolik práce, času a nervů, že napsat si jednoúčelově přesně to, co potřebuji, přímo v TeXu, je podstatně rychlejší a přímočařejší. Výchozí makro řeší sto padesát věcí, které se mě netýkají, ale ta sto padesátá první, kterou potřebuji, se kvůli tomu dostává za hranici možného.

Psal jste sice cosi o profesionálech, ale přitom jste přesně popsal amatérský přístup - podřídit konstrukci dílům, které má k dispozici, při velmi omezených technologiích, jež má amatérský kutil ve své garážové dílničce. Profesionál se nebojí vyrobení odlitku nebo vyfrézování nestandardního závitu, pokud je to účelné pro danou funkci. Z dílů stavebnice Merkur se dá postavit ledacos - třeba plotter - a stačí k tomu akorát šroubovák a klíč. Podle Vás by tedy profesionál takovou věc měl stavět zásadně z Merkuru nebo něčeho podobného, jen aby "nevynalézal znovu" V-profily, osičky, ploché profily, plechy atd.

"Brojím proti názoru, že pokud na něco existuje nějaká knihovna nebo generátor, tak že je _vždy_ výhodnější je použít." - pak neumite cist, protoze to jsem NIKDE nenapsal. Zatimco Vy jste napsal ze "casto" je lepsi opak (tj. napsat si to sam.

"Nebudu ztrácet čas detailním studiem generátoru a vymýšlením, jak narovnat, co generátor naohýbal, když si to mohu napsat sám z jedné vody načisto. Nakonec napíšu méně kódu, navíc přehlednějšího a jsem s tím hotov rychleji, než s generátorem." - ok, to je v naproste vetsine pripadu naprosta hovadina, navic na vsech frontach (rychlejsi - lol, prehlednejsi - lol, mene kodu - lol). Kdyby to tak bylo, tak by temer nikdo zadne generatory a frameworky nepouzival. To je cely SMYSL generatoru, aby to bylo rychleji, aby se napsalo VYRAZNE mene kodu a abych si mohl byt jisti ze je to spravne, protoze generator neudela chyby ktere udelam ja rucne.

"Podobnou zkušenost mám (a zdaleka nejsem sám!) třeba s LaTeXem - přiohýbání nějakého makra dá často tolik práce, času a nervů, že napsat si jednoúčelově přesně to, co potřebuji, přímo v TeXu" - ale tady prave narazime na to Vase nepochopeni me kritiky - ja nikdy netvrdil ze NIKDY neni lepsi si to napsat sam. Ale tvrdim, ze ve VETSINE pripadu je lepsi si to sam nepsat. Napr. ja jsem v latexu napsal desitky dokumentu, manualu, dopisu, prezentaci (beamer) a i diplomku - a jenom asi ve 2 pripadech jsem musel resit ze bych chtel neco co latex neumi . Opet, VETSINA pripadu pouziti latexu staci. A o tom se bavim o VETSINE pripadu, pro ktere jsou ty "knihovny, frameworky, generatory, apod." urcene - pro reseni BEZNYCH, opakovane se opakujicich situaci, ktere NEMA cenu resit manualne.

"Psal jste sice cosi o profesionálech, ale přitom jste přesně popsal amatérský přístup - podřídit konstrukci dílům, které má k dispozici, při velmi omezených technologiích, jež má amatérský kutil ve své garážové dílničce. Profesionál se nebojí vyrobení odlitku nebo vyfrézování nestandardního závitu, pokud je to účelné pro danou funkci." -lol - to si vazne myslite ze profesional je definovan tim ze si zamerne komplikuje praci? Pokud neni nejaky specialni duvod (a vetsinou neni), proc pouzit normalni normovany sroub, tak se pouzije normovany sroub. Tady nejde o zadny "strach", ale o to, ze profesional, v prvni rade, dela neco za PLAT. A nikdo mu nezaplati, ze misto obycejnych M8x50 frezoval vlastni srouby, nebo ze misto 2 beznych normovanych fitinku vyrabel model, formy a odleval si vlastni odlitky (navic naprosta vetsina strojnich firem dnes nema svoji slevarnu). Zakladni pracovni pomuckou KAZDEHO profesinala ve strojarine jsou normy, katalogy ozubenych kol, lozisek, apod. Protoze profesional vi, ze i kdyz stavi 5d obrabeciho robota, tak ty loziska, motory, srouby, tesneni a kabely vyrobi lip jini profesionalove.

Mozna si myslite ze "profesional" znamena "clovek co dela vsechno sam, protoze je nejchytrejsi na svete", ale ve skutecnosti je to clovek, co se danou veci zivi - je to jeho PROFESE. A jenom malokdo se uzivi tim, ze bude delat veci, ktere uz existuji znovu, zvlast kdyz nejsou kriticke pro to co dela.

".. Merkuru nebo něčeho podobného, jen aby "nevynalézal znovu" V-profily, osičky, ploché profily, plechy atd." - jak jsem psal, profesional ve strojarine ma katalogy a normy a v nich si ty "V-profily, osicky, ploche profily, plechy atd" najde. Protoze i kdyz muze prijit situace, ze bude potrebovat neco, co zadny znamy vyrobce nedela (a i pak je lepsi mu zavolat jestli nemuzou neco co maji dodat v jine specifikaci), obrovska vetsina veci se da vyrobit bud uplne z hotovych dilu nebo polotovaru.

Takze mozna jsem podle Vas straspytel, co se boji XML, coz me ale netrapi, a misto toho abych se nechal vyhodit za to, ze jsem mesic (spis teda rok..) nedelal nic jineho nez psal XML parser, a nic z toho co mam neni hotove.

Ta strojařina asi přeci jen nebyla zvolena nejšťastněji za analogii. Jednak se v ní evidentně vůbec neorientujete a jednak situace v IT je opravdu úplně jiná. K tomu prvnímu - zkuste si někdy rozebrat libovolný stroj a roztřídit součástky na ty standardizované a na "originály". Na první hromádce budete mít leda tak šroubky a matičky. A k tomu druhému - kdyby strojař postupoval jako ajťák, tak místo osobního auta postupně vytvoří samohyb ve stylu Pat a Mat, který váží asi tak 200 tun, žere kubík benzínu na 100 km, potřebuje pro sebe šestiproudou dálnici, občas mu sama od sebe zhasnou světla, občas se při vyhození levého blinkru zastaví, když na něj zezadu někdo zatroubí dvakrát krátce a dvakrát dlouze tak náhle změní směr a tisíc podobných závad. Ale pravdu máte v tom, že dokud bude růst počet šestiproudých dálnic, benzín bude stát desetinu haléře a dále zlevňovat a lidem nebude vadit v čem to vlastně jezdí, tak z ekonomického hlediska je ajťácký přístup v pořádku. Ovšem z toho inženýrského hlediska bych byl mnohem opatrnější - pozastavovat se nad tím, proč někdo vymýšlí speciálně tvarovanou nádrž na motorku (a tedy - podle Vás - "znovuobjevuje nádobu na kapalinu"), aby optimálně využil prostor a k jednotlivým částem motoru byl pohodlný přístup, když tam přece může vrazit plastový patnáctilitrový barel jen proto, že ho má zrovna po ruce, to už se obhajuje hůř. Bastlíř (amatér) se spíše spokojí s tím, co je k dispozici, nežli inženýr (profesionál), protože mu jde v první řadě o to, aby to vůbec aspoň nějak fungovalo, a těch momentů, kdy profesionál zvažuje řešení přesně šité na míru danému problému, je mnohem víc, než si amatér představuje. Nedělá to, protože by neznal typizovaná řešení, ani protože by měl času na rozdávání, ale protože řešení na bázi typizovaných komponent nepovažuje pro daný problém za daných podmínek za optimální.
Z IT se postupně stala těžká bastlířina, která má s inženýrskou prací pramálo společného.

Tím bych asi tuto debatu skončil, kdo chtěl tak pochopil, co se mi nelíbilo na paušálním odsouzení "netypického" řešení jen kvůli tomu, že je netypické, a proč jsem přesvědčen o tom, že není kolo jako kolo.

1. Jen do toho. Předchozí diskutér tvrdí, že strojař tak skutečně postupuje - ukažte mi tedy nějakou takto navrženou motorku. A připomínám, že diskutujeme pod článkem, který se netýká žádného softwaru na zakázku, jako jsou eshopy, weby apod.

2. Čím komplexnější komponenta, tím více má parametrů a tím větší je pravděpodobnost, že některé nebudou plně vyhovovat požadavkům. Amatér použije, co má, i za cenu zhoršení požadovaných výsledných parametrů. Profesionál zváží - i s přihlédnutím k nákladům, zda jde použít to, co je k dispozici, a když ne, tak chybějící komponentu vytvoří (nebo zadá nějakému specialistovi). Opakuji po několikáté a naposledy, že když někdo koukne pod kapotu motorky a řekne "hm, motor si vyvinuli sami - to je automaticky špatně, protože existuje spousta motorů do motorek", tak je to projev fachidiotismu. Může to být špatně, ale pravděpodobnější je, že pro to konstruktéři měli dobrý důvod. Jinak by tam nějaký hotový motor samozřejmě bývali dali.
A stejně tak si spousta programátorů raději napíše vlastní parser, přestože na ně existují generátory. Mezi námi, takový generátor se prakticky hodí tak na zpracování nějakého datového formátu nebo protokolu, a to ještě jen když se s tím nechci moc patlat, ale ne na zpracování reálného jazyka. Například mnou dříve uvedené nedostatky generovaného parseru jsou všeobecně známy - to, že tu nějaký Brouk Pytlík tvrdil, že to není pravda, jen dokazuje, že o tom nic neví a zkoušel si v tom dělat leda tak nějaký triviální učebnicový příklad ze zvědavosti - jestli vůbec.

Reagoval jsem na konkrétní příspěvek a celou dobu ho mám na mysli.
Sám jsem napsal, že situace ve strojírenství je jiná než v IT - viz výše. Sám jsem napsal, že profesionál si případně danou komponentu zadá specialistovi - viz výše. Dokonce bych řekl, že přestože každý profesionál by měl mít základní přehled o své profesi a tedy by měl být schopen si danou komponentu nějak navrhnout, neměl by se do toho pouštět, pokud cítí, že na to existují jiní specialisté a že on sám optimálních parametrů nebude schopen dosáhnout.
S čím jako inženýr zcela zásadně nesouhlasím, je to, že když jde o komponentu, ohledně níž nejsem specialista, tak že mohu použít první bazmek, který najdu, i když není dokonalý - jak píšete vy. To je amatéřina a ne profesionální práce! Hledám komponentu, která s ohledem ke svým parametrům, včetně ceny, podpory, autority, jež za ní stojí, autorům, spolehlivosti, testovatelnosti apod. bude vyhovovat co nejlépe. Nepošlu do kytek výkon nebo si neudělám bezpečnostní díru či jiné slabé místo do svého softwaru jen kvůli tomu, že s danou komponentou nechci ztrácet čas a neumím to. Nemusím být expert v oblasti, jaké se ta komponenta vnitřním fungováním týká. Ale pokud jsem se rozhodl ji použít, musím rozumět alespoň jejím vnějším parametrům.
Pokud lepíte svůj software z komponent, o nichž víte, že nejsou pro daný účel dokonalé, postupujete amatérsky. Nevěšte hlavu, tak dnes postupuje většina vývojářů v IT - a podle toho to vypadá a zákazníci jsou s tím většinou srozuměni. Tím "pro daný účel" je myšleno to, že nepotřebuji hledat tu nejlepší logovací komponentu, když jde jen o nějaké mé ladící potřeby. Ale rozhodně se nespokojím s nějakou pomalou/příliš složitou/příliš jednoduchou/příliš náročnou/nespo­lehlivou knihovnou, pokud to má vliv na požadované výsledné vlastnosti toho, co vyvíjím. Tak například budu-li psát software na Monte Carlo výpočet, nejprve zhodnotím použitelnost generátoru pseudonáhodných čísel ve standardní knihovně a pak budu hledat nějaký lepší. Může se stát, že půjde o nějakou specialitu a nenajdu žádný vhodný. Pak zvážím, zda jsem schopen napsat vlastní sám, nebo budu hledat někoho, kdo to pro mě udělá. Ale rozhodně se nesmířím s tím, že ten standardní není dokonalý a já nejsem expert na psaní generátorů pseudonáhodných čísel, když na jeho kvalitě stojí kvalita celého výsledku, resp. to může mít na kvalitu mého produktu negativní vliv.

Tak to je asi nedorozumění. Tou dokonalou jsem měl na mysli optimální pro daný účel, tj. i s ohledem k těm dalším parametrům, jež jsem uváděl. Neboli - aby nebyla zbytečně méně kvalitní. "Dokonalý" jakožto sémantický superlativ v kvalitativně-funkčním smyslu by byl dost abstraktní a odvážný pojem. Asi dvakrát jsem zdůraznil, co jsem měl na mysli, dokonce i typograficky.

aby to fungovalo alespoň nějak a včas. - Tak to už je ale nouzové řešení. To se dělá, když už něco hoří a mělo by jít opravdu jen o výjimečné situace, jež by rozhodně neměly být považovány za standard. Bohužel, v IT to standard je.

Ale to je něco podstatně jiného, než co bylo v původním komentáři. - Původní komentář byl ten, na nějž jsem reagoval a u něhož (nebo se mi to tak aspoň jeví) se shodneme, že dělat parser SQL pomocí generátoru bylo v tehdejší době asi nereálné (podle mě stále je), a že tedy kritika v tomto bodě nebyla na místě. Polemizoval jsem tu s názorem, že není důvod psát ručně parser, když máme generátory, a zobecnil jsem to na jakoukoli komponentu. Demonstroval jsem tu na několika příkladech a analogiích, že nejdostupnější řešení nebývá to optimální - tvrdím, že je to poměrně častý případ, bylo mi oponováno, že je to spíše výjimečný případ. Asi máme každý jiné zkušenosti, nároky nebo jsme jinak kritičtí.

Spousta vývojářů neví ani co mají dostupné ve standardní knihovně a píšou si to znova sami. - Je třeba rozlišovat, že nevědí, že to mají v knihovně, a že to vědí, ale nevyhovuje jim to. Naposledy opakuji, že na toto jsem celou dobu narážel, protože v tom prvním komentáři se toto nerozlišovalo - "chybí zdroj pro yacc, tedy autoři si psali parser sami, tedy je to řešeno nevhodně". Tedy nešlo o blíže nespecifikovanou "spoustu vývojářů", ale o vývojáře produktu, o němž je článek. Kdybych měl hodnotit práci "spousty vývojářů" zcela obecně, jak jsem měl možnost se s ní setkávat zejména v poslední době, tak bych jim vzkázal cimrmanovské "neprogramujte to - a pokud možno, neprogramujte vůbec", přičemž tendence je rok od roku horší a horší. Příliš často se střetávám s názorem "nejde to vygooglit, tak to neexistuje" nebo "není na to knihovna, tak to nejde"/"je na to knihovna, tak nad tím nebudu více přemýšlet". Mám rád takovou tu "kreativní" lenost, která vede k elegantním řešením. Nesnáším ale lenost používat hlavu, co vede k fušerství.

Tím bych se rozloučil, protože už tu akorát opakuji dokola dříve řečené a lépe to říci už asi nedovedu. Takže pokud je to stále nesrozumitelné, tak sorry.

> Abych se vratil k Vasemu autu: loziska, srouby (mozna krome ojnicnich), matice, podlozky, tesneni, apod. - pokud cokoliv z toho nejaky inzenyr navrhne vyrabet, misto koupit hotove, tak bude za blbce.

Jasně, normovaný součástky. Ve světě software bych to připodobnil k jsonu, http/s, TCP/IP a podobně. Standardizovaný pojivo mezi tím, co navrhne inženýr. To jest karoserie, blok motoru, kliková hřídel...

Zkus si třeba frézováním/sou­stružením/vrtá­ním do kusu plechu vyrábět pikslu od holící pěny. Blbost. Zvolíš jinej polotovar (tyč dvacítku?), jinej technologickej postup (protlačování), když budeš dělat jo velkou sérii, necháš si udělat ad hoc přípravky a nástroje. Protože snažit se používat univerzální nástroje tě vyjde dráž, než si zaplatit výrobu nástroje na míru. Nebo třeba kontrola těch podložek. Myslíš si, že na konci pásu "sedí bába se šuplerou", nebo že bábě dali do ruky na míru udělanej kalibr?

Jak jedna tak druhá extrémní cesta - používat hotový knihovny na všechno vs. psát všechno sám na zelený louce - jsou cesty do pekel. Dobrej inženýr (ať už strojní nebo programátor) dokáže říct "stop, dělat to takhle je blbost".