Názory k článku Programovací jazyk Go pro skalní céčkaře (2.část)

Omlouvám se, pokud se mýlím, ale přijde mi, že jste si sám odpověděl na otázku. Je naprosto běžné (nebo aspoň co se týče mých zkušeností), že na prototypu se staví výsledný produkt, přesně, jak píšete. Proto bych se neodvažoval dělat prototyp v něčem jiném, než by měla být ostrá verze, jedině s výjimkou, kdyby bylo jasné, že prototyp nebude takto použitelný. Aktuálně mne ale napadá jen jeden takový příklad z praxe - když Nintendo dělalo jejich poslední hru ze série Legend of Zelda (Breath of the Wild), nejprve mechaniky implementovali v prototypu s jednoduchou 2D grafikou, takže pak hru museli začít from scratch. (Zda ale použili různé programovací jazyky, to ale netuším.)

Ony jsou různé prototypy, od pouhých mockupů, statických HTML stránek s návrhem UI/dialogů přes polofunkční aplikace (kde se třeba simuluje databáze statickými daty) až po kostru výsledné aplikace. Ale právě pro tyto účely vznikly rapid prototyping nástroje a ty většinou nejsou postaveny na silně typovaných jazycích, spíš na Pythonu apod.

Já plně chápu váš názor a někdy je do toho tlačen i vývojář stylem "hele takto přesně to chceme, takže je vlastně hotovo, jen to trošku přeleštit". Takže je asi nutný dávat natvrdo informace, že se jedná o mockup, throwaway prototyp atd. (https://en.wikipedia.org/wiki/Software_prototyping#Throwaway_prototyping)

Pokud můžu mluvit za sebe, tak jedna z nejhorších fází projektu je právě situace, kdy je k dispozici +- slepenec, který se může podobat výsledné aplikace a má se začít kódit výsledný kvalitní(!) produkt. Člověku je líto ten slepenec zahodit s tím, že se to postupně doupravuje.

„Takže je asi nutný dávat natvrdo informace, že se jedná o mockup, throwaway prototyp atd.“

Jenže moje zkušenost je ještě tak trochu jiná. Vedení samo neustále opakuje mantru „je to jen prototyp, nějak to co nejrychleji nabouchejte, pak to zahodíme“. A ze dne na den (po schválení prototypu) se ona mantra změní na „nemáme čas, doděláme to na tom, co máme“. Všechny protesty vývojářů jsou smeteny ze stolu slovy „však to funguje“.

„Pokud můžu mluvit za sebe, tak jedna z nejhorších fází projektu je právě situace, kdy je k dispozici +- slepenec, který se může podobat výsledné aplikace a má se začít kódit výsledný kvalitní(!) produkt. Člověku je líto ten slepenec zahodit s tím, že se to postupně doupravuje.“

Popravdě, za tuto fázi jsem se už dávno dostal po několika projektech, které byly udělány na prototypu. Ty zkušenosti se vryjí tak silně, že ne, už mi to není líto zahodit. Naopak, vítám možnost některé věci napsat jinak, když při prototypování experimentuji s architekturou a zjistím, co není tak úplně ideální.

Na druhou stranu jsem zároveň nabyl dojmu, že se z prototypu dá udělat dobrý výsledný produkt. Jenže to vyžaduje ochotu a odvahu se pouštět do těžkého refactorignu a zjistil jsem, že podobně jak vedení bývá rezistentní vůči zahazování prototypů, tak většina programátorů je úplně stejně rezistentní vůči tomuto typu úprav. (Ale uznávám, kdyby to bylo v Pythonu nebo Java Scriptu, tak budu do určité míry rezistit taky. Ale v takovém případě bych v první řadě rezistil vůči použití těchto jazyků na větší projekt.)

Moje oblíbené řešení - udělat prototyp v něčem, z čeho nikdo nebude chtít tu produkci dělat. Vezmeš Haskell a jsi za vodou ;-)

Ono je možné to brát i z opačného úhlu: dělat prototyp v něčem jiném je způsob, jak zaručit, že se z něj nestane ostrá verze. Tohle se samozřejmě, až na čestné výjimky, v korporátech nemá šanci prosadit: jediným cílem všeho je vždycky snížit náklady teď hned a problémy se budou řešit "když nastanou", i když to pak znamená náklady řádově vyšší.

„Ono je možné to brát i z opačného úhlu: dělat prototyp v něčem jiném je způsob, jak zaručit, že se z něj nestane ostrá verze.“

No, přesně tak jsem to myslel, takže se omlouvám, pokud to vyznělo jinak.

A moji poznámku, že z praxe znám jen jeden případ jsem mj. myslel i tak, že i v tom vidím past. Řeknu si „Python není na tento projekt dobrý, ale rychle se v něm píše, takže ten prototyp udělám v něm“ a pak riskuji, že mi backfirene a samotná ostrá verze nakonec bude celá v Pythonu, jakkoliv je nevhodný. Takže jedině použít něco fakt šíleného, jako je Haskell zmiňovaný Ondrou...

Haskell je náhodou výborný jazyk na implementaci, ale jeden z nejhorších možných na prototypování.

Ok, beru v potaz; sám jej neznám dost dobře, abych byl schopný něco takového posoudit, takže jsem se jen odrazil od ostatních příspěvků.

@klokan - záleží na co. Já před časem potřeboval nasekat nejaké rozhodovací stromy nad Hadoopem a zrovna tohle se prototypovalo v Haskellu jedna báseň. Klikací aplikaci bych tak neřešil.

ony se ty rozdíly stírají. Dynamické jazyky přidávají možnost typových anotací a statické jazyky se postupně stávají uživatelsky přívětivější (typescript, Kotlin). Statické typy vnucované VŠUDE je podle mě přechodný trend. Třeba typescript je na ústupu. Nepřináší nic navíc oproti anotacím v komentářích, jen složitější ekosystém.

" Statické typy vnucované VŠUDE je podle mě přechodný trend. Třeba typescript je na ústupu"

To je spíš problému toho, že podvozek je prohnilý, ne? Kdyby se nemuseli držet života nad JS, tak statické typování jasně ukazuje, zač je toho loket.