Vlákno názorů k článku Senzory Martina Malého: Průmysl 4.0 nevzejde z brainstormingu na teambuildingu od Karel - Ale jo, lišilo se to. Najděte si nějaké...

Ale jo, lišilo se to. Najděte si nějaké návody na Turbo Vision, Java AWT atd. Typicky tehdejší problém byl "jak ty komponenty uspořádat na obrazovce tak, jak potřebuji".

Dnes se v návodech dočtete o tom, jak vytvoříte Model, Controler a pak jak vám z toho "systém" sám vygeneruje View. Že je to view úplně naprd, protože je udělané podle modelu a ne podle logiky vyplňování, se obchází leda tak tím, že má uživatel možnost si sloupečky popřetahovat. Dnešní frameworky zkrátka za programátora samy udělají práci, kterou dříve dělal programátor s designérem. A neudělají ji zdaleka tak dobře.

Ano, pro C třeba známé Vermont Views. No k těm změnám v programování se snad vymyká jen Rust a možná renesance funkcionálního programování a teorie kategorií a AI, ale i to už tu před 30 lety bylo, co nebylo, byl dostatečně výkonný hardware na kterém by to šlo rozchodit.

Základy byly položeny v 70. letech a od té doby toho moc nového nepřibylo.

Třeba ten Smalltalk.

Ale stejně tak byla propracovaná grafická rozhraní třeba i pro C, a další jazyky.

Ve své podstatě z celého IT programování za posledních 20 let prošlo nejmenšími změnami, a revoluce v programovacích jazycích či nějaká podstatná změna se nekonala. Programování i programovací jazyky stagnují, pokud se stvoří nový programovací jazyk, je to na jedno brdo kopie X jiných už dávno existujících.

Třeba Smalltalk :-)))

"Dříve nebyly tak univerzální grafické frameworky, GUI se muselo dělat, ale člověk to dělal hodně od nuly."

Já jsem před 30 lety (stejně jako mí spoustudenti na technické univerzitě) dělal s univerzálními grafickými frameworky, které nebyly moc odlišné od dnešních ve smyslu abstrakce a univerzálnosti.

to píšeš jen protože jsi v té době neprogramoval :). Podle odpovědi směřuješ k vývoji webu/mobilních aplikací, ať se tam poslední dobou vše přesouvá, pořád je SW vývoj daleko širší téma.

Dříve nebyly tak univerzální grafické frameworky, GUI se muselo dělat, ale člověk to dělal hodně od nuly. Návrhům UI se věnovalo daleko více prostoru (z osobní zkušenosti), one man show to mohla být kvůli tomu, že programátor neměl na dokončení dva měsíce, ale dva roky.

To je otázka míry. One-man show kde jeden programátor je analytik, designér, programátor i odborník na problematiku - může fungovat ve startupu. V okamžiku kdy firma trochu přestane stačit že to má "ten jeden v hlavě", protože je potřeba aby na tom dělalo víc lidí, a to už takto nejde.

Zvlášť pokud to prostředí na které je to zaměřené není úplně "stabilní" - právě zmiňované účetnictví může být značný problém, protože lze těžko předpokládat že programátor bude přes den programovat a po nocích makat jako daňař, aby dokázal držet krok v obou směrech - a zvládal vyrábět sw který to vše reflektuje (a navíc samozřejmě dokáže i konzistentně pracovat dle aktuálních zákonů dle toho, co zrovna zpracováváte).

Ano, i tato mentalita je součástí problému. Jestliže je ve vývojářském týmu někdo, kdo má pocit že nedělá analýzu a design, že jen plní zadání, bylo by asi lepší nahradit ho co nejdříve automatem.

Řešilo se to úplně stejně. Navíc odpor uživatelů byl mnohem intenzivnější.

Problém je v tom, že před 20ti lety bylo vše jednodušší - a podobný sw se dal udělat jako one man show - právě proto že to bylo jednoduché, prakticky neexistovalo GUI atd. Neřešilo se UX, neřešily se mobily, neřešilo se sto dalších věcí. Dnes to takhle dělat nejde.

Tohle ale neni v zadnem pripade problem programatoru. Programatori plni zadani analytiku a designeru. Problem je vynechani uzivatelskeho testovani navrhu a obecne setreni nakladu. Daleko vice jsou tohle problemy zpusobene spatnym managementem.

pan autor a vy jste taky pracovali na poště?

Přesně tak. Každá další verze programu situaci komplikuje, místo aby situaci zjednodušovala. Mám pocit, že programátoři píší SW tak, aby se jim dobře programoval, nikoliv tak, aby byl funkční pro uživatele. Máme dodavatele, který kdysi (před více než 25 lety) vyvinul základ SW a během let jej přizpůsoboval, piloval a ladil novým operačním systémům. Určitá uživatelská operace měla logicky uspořádané obrazovky a se dala udělat doslova za 5 vteřin. Pak se rozhodli, že je potřeba udělat SW znova, protože již původní návrh se přežil (ano, bylo potřeba), ale vše udělali tak, že ta samá uživatelská operace, je práce doslova na půl hodiny a obsahy jednotlivých obrazovek jsou naprosto nelogické. Když jsme se ptali, proč překopali původní funkční uspořádání obrazovek, nedostali jsme smysluplnou odpověď. Ale při pohledu do struktury databáze bylo jasno. Změnili strukturu dat (proč by ne, když je to potřeba), ale aby se jim to snáze programovalo, přizpůsobili zobrazená data (obrazovky) změněné struktuře dat a tím pádem program ztratil jakoukoliv logiku zobrazených dat pro uživatele. Takže páni programátoři jděte do ... pracovního procesu. Neuškodilo by vám trochu reálné praxe.