Názor k článku 602SQL Server: historie velkého produktu vyvinutého v malém týmu od Filip Jirsák - Původní komentář byl ten, na nějž jsem reagoval...

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ě.
Na tom se shodneme.

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.
Já jsem ten názor chápal tak, že k ručnímu psaní parseru musí být velmi dobrý důvod, standardní volba by měla být použít generátor, a teprve když se ukáže, že to fakt nejde, uvažovat o ručně psaném parseru. A s tím souhlasím. Ano, existují výjimky, jako např. právě nutnost držet zpětnou kompatibilitu až někam do středověku, což je případ třeba Oracle SQL. Ale první volba by měla vždy být použít už hotové řešení.

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.
Optimální (nejlepší) nebývá nic, ale ono stačí, když to splňuje podmínky – a pak je vhodné z dostupných variant vybrat tu (relativně) nejlepší. Vzhledem k tomu, že do kritérií řadím i čas vývojáře, bývá málokdy lepší programovat něco svého, když už řešení pro daný problém existuje.

Je třeba rozlišovat, že nevědí, že to mají v knihovně, a že to vědí, ale nevyhovuje jim to.
Já jsem psal o prvním případu, se kterým se setkávám.

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ě".
Ano, ale v tomto případě byla chyba v tom, že se dotyčný nezamyslel nad tím, zda se náhodou nejedná o tu výjimku, kdy použití hotového řešení není nejlepší volbou.