Ekonomismus vs Programátorismus

11. prosince 2008 v 0:32 |  Sapiens
Začnu nejdříve kamenem v botě. Nedomnívám se totiž, že to, na čem lidstvo pracuje, je vskutku důležité, a to zejména v případě vědeckého developmentu1. I kdybychom přijali axiom2, že vědecký development je izolovaný od spotřebního mechanismu3, kdo zaručí, že priority vědeckého směřování jsou opravdovými hodnotami pro lidstvo4? Na druhou stranu, kdo zaručí, že prostředí, které nám nastoluje ekonomika a odvislá ekonomie5, je opravdu užitečné, a nikoli například nebezpečné6? Budiž kámen v botě.



Nyní tedy přistupme k instalaci dalšího teoretického systému do vaší privátní mašinerie, předem prosím, zvolte kategorii experimenty, nebo humor, a vyvarujte se užití kategorie "základní", neboť jde o alfa verzi, která může vést k výraznému snížení adaptivity nebo rozostření selektivity adaptéru vašeho interface. Ovšem jako každá odborná literatura ani tento článek nemusí být ihned řazen mezi "uvolněné kategorie"7.

Berme nyní oba basické milníky z abstraktu jako pominutelné: znáte určitě mnoho případů software, kde ohnisko práce, po celou dobu rekonstrukce systému, leželo omylem právě v uživatelských pochoutkách, a základní podpora a interfacing datového rozhraní zůstal opomenut. Kupříkladu si představme, že vyvíjíme komplexní informační systém, a všechno nízké řešíme právě jen základními vstupy typu DbConnection a DbCommand. To samo sebou vede k tomu, že si práci zkomplikujeme, a nikoli zjednodušíme o výchozí ANANAS. Ale především nikdy nevíme, zda už tento krok - vynechání analýzy - nebyl závazkem k ďáblu: jinými slovy, většinou takový projekt nemá šanci na přežití. Jenže co je horší, je, že takové plýtvání kódem lze injektivně zobrazit v reálném programovacím jazyce - světě. Stačí si jen představit, že každý přímý vstup je nějaká ta tuna neobnovitelných zdrojů - každé přímo použité slovíčko DbConnection má svoji hmotnou podstatu, například tuna jaderného odpadu rozptýleného v moři, jedna světová válka, nebo deset hladomorů. Jenže rozhodně nechci tímto článkem nějak učit developery programovat, nebo byznismeny podnikat.

Spíše se vraťme k reálné zátěži, která tímto padá na hlavu programátorům daného IS. Jakmile už je projekt natolik široký, že v podstatě souhlasí se svým architektonickým návrhem, který je velmi povrchní, nelze jej vnitřně pořádně spravovat. Programátor podléhá časem duchovní zkáze, ve svém chaotickém systému se stěží vyzná, ať už vydal jakékoli úsilí v celkově beznadějné situaci, kterou mu zadavatel svou hloupostí přines. Sám si ve svém světě přijde jako vyrovnaný cizinec v kutlochu schizofrenika: chaos, chaos a perversity. Všude jen improvizace, svědčící o nekonečné snaze analytika vyhovět plánům psychopata. Další podstatnou vadou, která nyní přichází na světlo jsou zpětné zásahy: jakákoli malá změna může vyvolat dávné duchy, v podobě kolosálních chyb, a každá úprava tak znamená velké riziko rozpadu projektu. Nakonec lze podotknout, že také dojde zákonitě k nálezu neodstranitelných chyb nebo alespoň omezení vývoje projektu, například na základě jednoho špatně navrženého databázového elementu, třeba rodičovské vazby typu FTA, která oproti RID systému rozvoj aplikace opravdu dále neumožňuje.

A zpátky do světa: je až neuvěřitelné, nakolik se podobá ekonomismus, tedy
"nákup->prodej->vývoj"
právě hašteřivému zadavateli, který naprosto nechápe důležitost ANANASU, ale na první frontě už zamořuje všechna namespace hodnotnými uživatelskými fíčrami. Samozřejmě je to podobné i tím, nakolik je soudobá ekonomika nestravitelná environmentem, nakolik je zátěží na psychiku, a nakolik je schopná efektivně užívat dosažených interfacingů (porovnej stav vědy se stavem továrnictví). Zároveň je zřejmé, že v dnešní době není možné experimentovat na žádném z vyšších levelů interface, ačkoli běžně je tato možnost považována za základní metodu výzkumu výhodnějších konfigurací. Jenže to nejhorší je trošku jiné podstaty: s tím vším, co bylo shrnuto, je zřejmé, že neplánované projektování je jako procházka po neoznačené střelnici, nebo, z hlediska programátora jako pobyt kočky s extrémně dlouhým ocasem v místnosti plné houpacích křesel. Z hlediska funkční metaforiky můžeme práci "vrchního programátora interface lidstva" shrnout jako projekt hrnoucí se šmahem do záhuby, ale to nás samozřejmě nezajímá. Takové projekty jsou od toho, aby se revampovaly a kanibalizovaly.

Oč mi tedy jde v ústřední sekvenci tohoto TS? Pouze několik otázek:
Jak by měl vypadat efektivní developerský simulátor světa?
Je zde nějaká datová base, kterou je možno enkapsulovat?
Jak postupovat v analýze, která by měla odhalit nejvýhodnější návrh formulace lidstva,
a zároveň vyprodukovat i číslo, korelující s časem, kterým bude současná snaha lidstva
odložena. Např.:
hpt "robotika" -> vývoj robotiky, zavedení robotiky -> pokračování v současném směru
H -> A(H) -> X
OP("A(H)") = TimeSpan
Hrají peníze vhodnou testovací roli, která by neměla být z procesu AH vyloučena, například tedy zda nějak popisují náročnost či kvalitu operací?
Mají být peníze aplikovány na implementaci AH?


Nyní už jen pár fantazií na téma. Určitě by bylo možné vytrhnout lidstvo z jeho zapáchajícího schizofrenikova lůžka, vypnout mu jeho ekonomistickou8 televizku, a během několika let neutuchající komunistické spolupráce vyvinout mu pod nohama přehledný robotický, programovatelný aparát. Jinými slovy vykálet se na výroby typu "VolksWagen" či "Zanussi", a rovnýma nohama narýsovat univerzální modulární faktoristiku, tedy např. krychlovou modulární halu, obsahující robota, schopného opatřit danou součást během mžiku celým rastrem modulů, nebo také nějakou součást vyrobit. Samozřejmě by už byl brán patřičný ohled na prostředí, a to nejlépe nulová zátěž a minimální opotřebení i údržba. Taková robotika by lidstvu samozřejmě vytrhla ze srdce jeden velký problém - těžkou práci - tedy práci jednoduchou a ubíjející, zhovadilou. Také je velmi myslitelné, že z hlediska opotřebení bychom měli mluvit o výrobě této mechanizace ve vesmíru, nebo dokonce jejím užívání v takovém prostředí.

Osobně bych byl nadšený, kdyby lidé měli ty jejich hovadiny (viz elektronika, lékařství, vozidla...), a přitom by ani nemuseli hrábnout prstem - tedy až na to, že by měli spoustu času na efektivní zemědělství, všichni.

Také vyvstává otázka, zda taková modularizace, resp. robotizace, není dobrou extenzí přírodního živlu: na zeleni a červeni kovová struktura propouštějící aktivně světlo, a zároveň absorbující maximum vesmírné energie pro metaúrovňové programování.

Jako zásadní identifikátor extremity tohoto TS můžete použít tuto MNT pomůcku:
nic z vyřčeného nebude zdaleka tak snadné, jako říci v samoobsluze "10 deka droždí".

Číslované poznámky:
1) = vývoje. Je tím myšleno to, že lékařství má vůbec slovo, ale také to, co má v lékařství slovo.
2) kdyby tomu tak prostě bylo
3) tím je myšleno to samé jako v b. 1, jen přeneseno do sféry konzumní výroby
4) to znamená, že např. lékařské doplňky imunity mohou ve výsledku stát za zrodem ještě horších soupeřů - až nakonec lékařské doplňky půjdou hodně hluboko do lidské podstaty a za hranice humanity, aby bylo lze s novými mikrobojovníky ještě zápasit: takřka tím, že si proti rýmě vytrhneme vous poskočíme k tomu, že si kvůli rýmě456 vyřežeme páteře.
5) to, že vyvíjíme vědu o spotřebě, a tou pak řídíme spotřebu ...
6) nyní prosím všechny čtenáře, kteří už mají sto důvodů se hašteřit o svých zkušenostech s komunismem či kapitalismem, aby se laskavě odpoklonkovali, zdaleka nejsou vítáni
7) takovou složku mám na svém PC na dokumenty, které jsem vytvořil během období, která jsem s odstupem ohodnotil jako "vykolejená", zkrátka můj vlastní psychiatrický šuplíček, dokonce i s rohožkou před východem.
8) tlačítkem nebo ovladačem?
 

Nový komentář

Přihlásit se
  Ještě nemáte vlastní web? Můžete si jej zdarma založit na Blog.cz.