Na váš příspěvek bych cimrmanovsky reagoval slovy "nevím věru, co vám mám vytknout dříve".
Jednoduché řešení v software není správné, protože software není jednoučelová elektronika, software je živý produkt, který se po dobu života neustále proměňuje, proto i ten nejjednodušší problém musí být řešen s ohledem na pozdější údržbu a modifikace.
Nesmysl. Software není ničím vyjímečný oproti jiným věcem. I elektronika se vyvíjí a vytvořit nový návrh DPS kvůli drobné změně návrhu pro novou verzi je vždycky poměrně drahá záležitost. Dokázat předjímat možný vývoj v budoucnu je úkol pro geniální mozek, jenže přiznejme si, že 99,99% mozků, které na sebe tento úkol poněkud neskromně berou, není geniálních. A podle toho to pak taky vypadá.
tedy jednoduchým ad hoc řešením, zaděláváte si na problémy, protože bude vše takto řešit a jeho produkt bude nakonec neudržovatelný
S tím v žádném případě nesouhlasím. Vaše odhady budoucího vývoje budou velmi pravděpodobně chybné, to není žádná urážka vašeho intelektu, to je empiricky dokázaný fakt. Bude vás to stát více námahy a budoucímu vývoji to nijak nepomůže, spíše naopak, nakladete do cesty hromadu zbytečných překážek, jež pak v budoucnu někdo bude muset odstraňovat nebo jinak překonávat, aby implementoval požadovaná rozšíření, jež jste neměl šanci předpokládat.
Každý si hraje s jinou stavebnicí, elektronikova má 50 kostek, programátorova jich má tisíce, protože v prostředí programátora neexistuje fyzika, která by ho držela v rozumných mezích a cest, kterými se může vydat, je velmi mnoho.
Vůbec ne. Elektronik pracuje v analogovém kontinuu, jeho možnosti jsou nespočetné - má to řešit analogově či digitálně, kombinačně či sekvenčně atd. Programátor je limitován hardwarem, konstrukcí procesoru. Elektronik se může rozhodnout, zda nějakou veličinu zintegruje analogově integračním obvodem nebo si ji zdigitalizuje a provede to nějakou sčítačkou. Programátor tuto možnost volby už nemá. Sám počítač je limitován fyzikou, tím spíše je programátor limitován ještě kromě fyziky navíc i počítačem.
Životnost elektroniky je pár let, životnost software je desítky let.
To snad ani nemá smysl komentovat. To jste si asi po sobě ani nepřečetl, jinak by vám okamžitě muselo dojít, jakou blbost jste napsal.
Je to o způsobu myšlení, které u programátora by mělo být jíné, než u elektronika.
S tím jediným se dá souhlasit. Krásně je to vidět, když se programátor pustí do návrhu s FPGA.
Celkem vzato ale pravdu nemáte. Vlastně jste tu shrnul zásadní nešvary a prohlásil jste je za přednosti či nutnosti. Výsledkem je software, který v poměru k tomu, co se po něm doopravdy požaduje, je neuvěřitelně nenažraný, poruchový, pomalý a k jeho vývoji a údržbě je třeba neuvěřitelné množství lidí. Aby se ušetřilo, jsou v IT angažováni i lidé, kteří na to fakticky nemají schopnosti a vymýšlejí se metody, jak umožnit i těmto lidem, aby se do vývoje mohli zapojit, čímž se celá situace jako v začarovaném kruhu dále zhoršuje.
Stačí se seznámit s myšlenkami lidí, jako je Thompson, Knuth, Wirth, Moore, Kay, Wozniak a dalších, které považuji za guru v oblasti počítačů. Všichni by vám řekli, že základem je držet se pravidla KISS (Keep It Simple and Stupid) a že největší problémy si člověk do cesty naklade podvědomě on sám tím, že si do zadání promítne různá omezení a předpoklady, jež ze samotného zadání vůbec neplynou. Krásně o tom píše Moore (když porovnával svůj OKAD s profesionálními produkty), na přednáškách to na lidech demonstruje Kay (zadání: napište program v LOGO, který nakreslí kružnici) a Knuth tento problém zmiňoval, když mluvil o tom, jakým způsobem vymýšlel TeX (volba základní měrné jednotky). Thompson se toho dotknul, když vzpomínal, kolik lidí a kódu spotřebovala detekce deadlocků v Multicsu, ačkoli se ukazovalo, že k takovým situacím v praxi téměř nedochází. A všichni se shodují na jednom: při vývoji se v žádném případě nepokoušejte předvídat, jakou cestou se projekt bude ubírat v budoucnu; neuhodnete to, zákon schválnosti funguje stoprocentně, co jste předpokládali, to nikdo nechce, ale zato to zkomplikuje implementaci toho, co se pak ve skutečnosti chce. Neimplementujte nic jen kvůli tomu, že to jde, nebo protože si myslíte, že by to někdo mohl potřebovat. Pokud nějaký problém počítá ze zadání s čísly 0..32 a neexistuje žádný technický nebo jiný problém, proč nepoužít celý bajt nebo celé slovo, není důvod se zbytečně omezovat. Ale na druhou stranu není důvod si to celé zkomplikovat použitím nějakého dynamického objektu, umožňujícího i řetězce a odkazy na obrázky. Protože podle zákona schválnosti nikdo nebude potřebovat obrázky, ale větší rozsah čísel a co nejrychlejší zpracování.
119 Odpovědí
19067 Zhlédnutí