Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: lojza 04. 01. 2016, 17:43:30
-
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ? nejde mi ani tak o vysvetlovani jednotlivych paradigmat, natoz syntaxe, spis o nejake "kulhajici"zobecneni neprenosnych ? zkusenosti za roky co se venujete programovani ? asi to nejde co ? ja vim ze nikdy umet programovat nebudu tak bych chtel jen zazit ten pohled na svet Vasima ocima ...
-
A co si to rovnou vyzkoušet vlastní hlavou? http://robiebobie.sweb.cz/
-
diky zkusim, ale jsem spis takovy filosof-teoretik ktery se proste rad jen "neprakticky"zamysli treba nad tim, jak formuje dlouholete programovani mysleni cloveka, ktere se asi uplatnuje treba i v beznem zivote (stejne jako treba pravnicke mysleni atd..), zkratka asi by me zajimal
https://en.wikipedia.org/wiki/Mental_model tech lepsich programatoru
nejake clanky jsem uz zkusil hledat v Googlu, treba
Mental models, consistency and programming aptitude.
-
Nijak.
Programátoři jsou také běžní smrtelníci, byť určitá profesní deformace se u nich může projevovat jako v každém jiném povolání. Spíše než na programátory a ty ostatní bych lidi dělil třeba dle:
https://cs.wikipedia.org/wiki/Myers-Briggs_Type_Indicator (https://cs.wikipedia.org/wiki/Myers-Briggs_Type_Indicator)
...přičemž každá kombinace se může hodit pro jiný druh práce, nejen z pohledu technického, ale i sociálního (programátoři nejsou jen "programátoři", v praxi dělají spoustu jiných činností než psaní kódu).
-
asi se neumim presne vyjadrit, treba nekolik "programatoru" co jsem v zivote potkal, mi nezavisle na sobe reklo kdyz jsem se jich ptal v cem programuji, ze ted v X.Y ale ze je to v podstate jedno, ze by se docela rychle naucili programovat i v jinem jyzyku a z toho pro mne vyplyva, ze musi "na pozadi"existovat nejaky spolecny jmenovatel, zkusenost, schopnost, pochopeni, zrucnost ktere programatori maji a jini lide kdyz konkretni programovaci jazyk nehraje "äz takovou roli"a nevidi to jako zasadni problem do budoucna se preucit pripadne na neco jineho a v tom si dal vydelavat na zivobyti ...
-
Co mysleni, ale hlavni je, ze typicky programator ma kolem kazdeho prstiku omotanou jednu zenu, zeny totiz miluji programatory, nemohou odolat tomu tukani do klaevesnice a jejich sexy mozkum, obzvlaste kdyz porad neco logicky rozebiraji. A to tak moc, ze jim ani nevadi, ze by programator nepreckal jedinou zimu v divocine a nesjpise by ho po par dnech sezrala liska nebo uklovala vrana; obzvlaste programator linuxak trpi timto hendikepem.
-
Na pozadí existují programovací paradigmata. Třeba programátor v Javě se snadno naučí (OOP část) C++ či Python, protože tyhle jazyky mají stejné paradigma, ale takový Haskell (či šablony v C++) se bude učit poměrně dlouho, pokud se vůbec dokáže oprostit od jím zažitého paradigmatu.
-
mne to prijde ze na pozadi musi byt neco magickeho, vzdycky jde o "problem solving"a proste ten pohled na problem a jeho reseni Vy "vidite jinak" nez zbytek populace ?
-
Programátor musí umět myslet jako stroj, dobře to ilustruje tento vtip:
Žena posílá manžela programátora na nákup: “Kup dvě nožičky klobásy a když budou mít vajíčka, kup jich deset.” Muž jde na nákup: “Máte vajíčka?” “Ano.” “Tak mi dejte deset nožiček klobásy.”
Nemusí samozřejmě takovým způsobem uvažovat stále, většina programátorů umí přepnout myšlení do režimu kompatibilního s normálními lidmi.
-
diky zkusim, ale jsem spis takovy filosof-teoretik ktery se proste rad jen "neprakticky"zamysli treba nad tim, jak formuje dlouholete programovani mysleni cloveka, ktere se asi uplatnuje treba i v beznem zivote (stejne jako treba pravnicke mysleni atd..)...
Programator ma zadany nejaky problem, ma k dispozici nejake prostredky pro jeho reseni, tak se snazi ten problem vyresit. Nic vic bych v tom nehledal.
-
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ?
Pohled na svět se liší v úrovni chápání světa, programátor většinu času tráví úkolováním počítače který je od výroby velmi hloupý a je schopen úkonů pouze jenom asi jako rychlá kalkulačka. Proto programátor musí umět více chápat dění v reálném životě a být schopen tyto poznatky přenést do počítače. Obecný příklad je programování řídící jednotky výtahu, neprogramátor si to představuje jako že to se jenom zmáčkne čudlík a je to hotovo, programátor za tím vidí měsíc perné práce, jak naučit "kalkulačku" spolehlivě jezdit nahoru a dolu.
-
Možná je to jen schopnost daný problém rozdělit na přiměřeně menší problémy, ty dále rozštěpit na ještě menší problémy, až se dostane do stavu, že ten drobný problém už někdy vyřešil, vyřešil ho někdo jiný nebo je schopen ho sám vyřešit. Pak následuje syntéza těchto drobných řešení do celkového řešení.
Podstatné je přitom udělat co nejméně chyb a vyřešit to tak, aby dokázal začlenit i případné změny, pokud zadavatel změní parametry toho problému.
A v neposlední řadě si v tom všem udržet pořádek.
-
no mne slo nadnesene o to, jestli nevedome (nebo z casti vedome) kdyz pouziju ten priklad s vytahem programator pri vstupu do vytahu uz automaticky nerozklada na prvocinitele, deklaruje v hlave zakladni promenne, "debugguje"... a to tak ze si to ani neuvedomuje jak kraci zivotem, ma "jinou vsimavost"pro detail nez bezni lide ... napadaji ho "problemy k reseni"ktere by slo monetizovat a ktere jiny nevidi
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
Programator, ackoliv je v ramci IT sveta v podstate delnicka profese, tak jiste znaky analytickeho mysleni potrebuje.
Rekl bych, ze obecne bude mezi programatory relativne malo lidi vericich (ve smyslu nejakeho nabozenstvi).
A ano, programator je clovek ktery rad vidi nejaky cil, konec, reseni problemu. Na rozdil od tech mene prirodnich vet kde 50 popsanych stranek nemusi znamenat vubec zadny zaver(ackoliv penize z grantu prozrany byly)
-
no mne slo nadnesene o to, jestli nevedome (nebo z casti vedome) kdyz pouziju ten priklad s vytahem programator pri vstupu do vytahu uz automaticky nerozklada na prvocinitele, deklaruje v hlave zakladni promenne, "debugguje"... a to tak ze si to ani neuvedomuje jak kraci zivotem, ma "jinou vsimavost"pro detail nez bezni lide ... napadaji ho "problemy k reseni"ktere by slo monetizovat a ktere jiny nevidi
Tohle nesouvisi s povolanim nebo oborem. Steve Jobs nebyl programator. Obecne programatori IMHO jsou velmi slabi prave v monetizaci a reseni veci ktery je nepali.
-
kdyz vlezu do vytahu a pominu nizkourovnove uvahy o hardware a ovladani mikrocipu, relatek, tlacitek, displeju,
tak muzu treba premyslet jaky by byl vhodny model pro chovani vytahu.
napr. je lepsi pribirat lidi v patrech, reagovat na tlacitka i kdyz vytah jede.
co treba kdyz vytah dlouho zahali, nebylo by jej lepsi automaticky odeslat do prizemi.
nebylo by nejlepsi kdyby vytah cekal v prostrednim patre, aby byl stejne rychle dole jako nahore.
pakvsi muzu rici jak tohle zapsat do kodu.
-
podla mna musis mat velmi silnu schopnost abstraktne mysliet. vela krat rozmyslam v programovacom jazyku cez bezny den a potom uz viem ze ked si sadnem za klavesnicu tak to napisem tak a tak. je to strasne zvlastny pocit, ktory pride az so skusenostami, ale deje sa to a verim ze sa to nedeje len mne. uz mas nejaky jazyk tak zazity ze v tom vies proste rozmyslat. ako by si mal vyriesit nejaky rebus a v hlave prides na riesenie. ono ani nejde o to, ze by si to vedel "uplne presne" ako to a tamto odkodit, ale staci ti viac menej zhruba vediet, akym sposobom ten problem atakovat a v hlave ti vznikne hruby nastrel ked _vies_, ze bude spravny a potom je to len otazka konkretnej implementacie.
mozno sa to nezda, ale programovanie je dost o mentalnej praci. stale a stale len rozmyslas, refaktorujes, abstrahujes, generalizuje a zapuzdrujes ...
-
no to vypada ze trenovane mysleni ovlivnuje vnimani reality a asi jedine vedomym usilim se pak muzu snazit se ho docasne oprostit ... musi byt zajimava prace (jestli nekde probiha) treba v tymu kde na jedne strane cisty teoreticky matematik kteremu z rovnic vychazeji nejake nove pohledy (reseni) predpovedi, fyzik ktery by to rad testoval jestli to panBuh takhle opravdu myslel a programatorem ktery ma umoznit fyzikovi ten experiment provest (merici zarizeni apod.), to cele v nejakem x-dimensionalnim prostoru, ktery je lidskemu "rozumu"nepristupny si predstavit, je nenazorny, ale matematicky sedi ...
-
lenze ten programator nemusi vediet vzdy uplne vsetko do podrobna ako to ten matematik myslel. naco by mu to bolo? samozrejme, moze sa o to zaujimat a moze si to dopodrobna nastudovat, ale velmi, velmi zriedka sa stane, ze to ma programator odkodit uplne vsetko cele odznova. vzdy proste len nadviaze na pracu niekoho a dorobi tam to co chyba. na to nutne nemusis vediet, ako uplne vsetko cele dokopy funguje. staci ti, ak sa velmi rychlo zorientujes.
-
Programatorske mysleni: Ja bych rekl, ze musis umet dobre zobecnovat.
Nekdy se hodi, narozdil od realneho zivota, kde je tomu asi presne naopak, uprednostnovat obecne principy pred jejich konkretnimi "instancemi".
Napriklad asi pred pul rokem jsem mel ukol rozparsovat nejaky velky textak z jednoho toolu a vygenerovat z toho CSVcko. Navic mel uzivatel jeste domain-specific "prani", ktere konkretni vysledky z tohoto obecneho rozparsovani jsou relevantni a ktere musim zahodit.
Tak jsem udelal dva skripty: jeden, ktery parsoval obecne a druhy, ktery "vyhazoval" nebo nechaval ty specificke radky.
A bylo to vtipne v tom, ze jsme se s uzivatelem neshodli na terminu "cisty": uzivatel povazoval za "cistou" tu kombinaci obou skriptu, protoze prinasela vysledky, ktere on zrovna chtel. Pro me byl "cisty" naopak ten prvni skript, protoze parsoval obecne dana data a nemel tam zadna konkretni "magicka cisla".
-
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ? nejde mi ani tak o vysvetlovani jednotlivych paradigmat, natoz syntaxe, spis o nejake "kulhajici"zobecneni neprenosnych ? zkusenosti za roky co se venujete programovani ? asi to nejde co ? ja vim ze nikdy umet programovat nebudu tak bych chtel jen zazit ten pohled na svet Vasima ocima ...
vytěžil jste z dosavadních odpovědí nějaké poznatky? :)
-
A bylo to vtipne v tom, ze jsme se s uzivatelem neshodli na terminu "cisty": uzivatel povazoval za "cistou" tu kombinaci obou skriptu, protoze prinasela vysledky, ktere on zrovna chtel. Pro me byl "cisty" naopak ten prvni skript, protoze parsoval obecne dana data a nemel tam zadna konkretni "magicka cisla".
Pokud by ten druhý skript byl parametrizován dalším souborem podobného typu jako třeba .gitignore, byly by programátorsky čisté oba dva skripty, resp. ten první by pozbyl na významu. Programátor kouká, zda má čistý program - bez skrytých závislostí. Uživatel zase chce mít čistá data - bez těch zbytečných.
-
zajimave muselo byt urcite treba programovani v NASA pro projekt Apollo, pozdeji pro raketoplany, nebo i obycejnejsi programy pro Airbusy nebo rizeni letoveho provozu, asi by se mi trochu roztrasly kolena kdybych vedel ze programuju neco na necem fyzicky visi zivoty lidi, ono ale asi i treba internetove bankovnictvi, burzovni sw pro algorithmic trading atd. musi byt zajimave
co podle Vas ma ted nejvetsi perspektivu (dejme tomu na 40 let dopredu, dal asi videt neni ? AI, machine learning, support decesion sw, data mining, nebo se v tomto stoleti dockame nejakeho (dnes to jeste je jen na papire nebo ani to ne) fakt prulomu ktery se dnes zda spis sci-fi ale bude realitou, treba opravdu myslici stroje samoucici, selfrepairing, ktere zastoupej primo lidi pri rozhodovani (vzdyt treba letadla by uz mohly brzy samy vzletat a pristavat) apod. umoznujici treba bruteforce metodou otestovat vsechno v domenach, ktere jsou nam zatim nepristupne, kvantove pocitace, vzdyt treba i zmena pocasi je deterministicka jen nemame tu silu to vcas vypocitat (deterministicky chaos), asi to spis budou veci az pro 22. stoleti ?
jsem laik treba mluvim hlouposti, ale zajimalo by mne jak to bude v roce 2050, 2100, mam pocit ze ted se jen dotahuji stare koncepty do detailu ale nic noveho na obzoru ?
-
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ? nejde mi ani tak o vysvetlovani jednotlivych paradigmat, natoz syntaxe, spis o nejake "kulhajici"zobecneni neprenosnych ? zkusenosti za roky co se venujete programovani ? asi to nejde co ? ja vim ze nikdy umet programovat nebudu tak bych chtel jen zazit ten pohled na svet Vasima ocima ...
vytěžil jste z dosavadních odpovědí nějaké poznatky? :)
urcite je to pro mne obohacujici dozvedet se neco o pohledu na svet jinyma ocima, snazit se vtelit do Vas byt jen v predstave a pokusit se videt svet Vasima ocima
-
zajimave muselo byt urcite treba programovani v NASA pro projekt Apollo, pozdeji pro raketoplany, nebo i obycejnejsi programy pro Airbusy nebo rizeni letoveho provozu, asi by se mi trochu roztrasly kolena kdybych vedel ze programuju neco na necem fyzicky visi zivoty lidi, ono ale asi i treba internetove bankovnictvi, burzovni sw pro algorithmic trading atd. musi byt zajimave
Není to tak zlé. U těch letadel a raketoplánů jsou nižší nároky na produktivitu a je tam vícestupňová kontrola, takže pokud jeden programátor něco zvorá, tak jiný tu chybu odhalí. A vše se pořád dokola testuje - testy bývají i dvacetkrát delší než produkční kód a simulují i závady na hardware, protichůdná data z různých čidel apod.
-
Vezmu to za sebe.
Všiml jsem si tohoto: Přestal jsem věřit lidem a hlavně pak sobě.
Proč? Inu chyby v myšlení a chyby při práci člověk dělá velmi často. U programování mívají z velké části fatalní následek (program něběží, padá a pod.). I když se programátor snaží, věnuje se programování naplno a pečlivě, vždy se tam nějaká chyba objeví. Uvědomil jsem si, že lidský mozek (i když se zdá, že funguje perfektně) dělá často chyby a zkracuje uvažování pomocí heuristik a odhadů.
Co to mělo za následek?
Pokud mi člověk přednese nějaké důležité tvrzení, prozkoumám jej opravdu důkladně. Rozložím jej stejně jako když řeším/implementuji nějaký problém. A často naleznu chybné logické závěry, kontradikce a pod., kterých si sdělovatel není vědom.
Dále jsem si všiml, že se mi zlepšilo logické a dedukční uvažování a jsem (doufám) méně chybový při sestavování logických závěrů. Nebo se alespoň častěji kontroluji. Taky jsem si všiml, že jsem schopen změnit názor na danou věc velmi rychle, pokud se ukáže logická chyba v mém uvažování. To je něco, čeho nejsou například věřící lidé schopni - zbavit se v okamžiku víry, i když je jim ukázána logická chyba.
Také jsem si všiml, že spousta věcí ve světě je navržena velmi neefektivně, redundantně, chybně. Zvlášť si toho člověk všimne, když programuje nějaký realným program, který se zabývá člověkem definovanými pravidly.
Jsem zvyklý na vysokou kvalitu kódu a to ne jen z pohledu, jak je to napsáno, ale hlavně z pohledu, jak je to vymyšleno.
Také si člověk všímá věcí, které jsou opravdu velmi pěkně vymyšleny a je slast je studovat a implementovat. Zvlášť se jedná o čistě matematické věci.
Pro mne vystavení intenzivnímu přemýšlení a programování v průběhu mnoha let znamenalo pozitivní změnu v mém uvažování.
Samozřejmě, toto nemusí platit, jen o programování. Programování (testování, verifikování) ale dává neustálou zpětnou vazbu.
Navíc dává člověku schopnost realný problém správně rozložit na podčásti a vztahy mezi nimi a ty pak popsat pomocí základních matematických formulí a struktur. Tím pak lépe chápe význam a fungování dané věci, (ale často i chyby autora dané věci).
-
obecne, silna stranka programatora je schopnost rozpadnout slozitou ulohu na jednodussi jednoduse resitelne ukoly. nejlepe co nejvic opakujici se.
naopak, drtiva vetsina programatoru postrada fantazii na opacnou ulohu, hladat abstraktnejsi tezko rozlozitelne souvislosti.
filozof a programator jsou docela protihlehle pristupy, kupodivu dost programatoru ma tandence podivne filozofovat, nastesti vetsina filozofu neprogramuje
-
Myslím, že mňa programovanie v bežnom živote moc nezasiahlo, alebo si to neuvedomujem. Občas sa ale chytám za hlavu, keď mi neprogramátor v práci na otázku typu "Chceš to červené, alebo zelené?" odpovie "Áno".
Ale inak napadla ma paralela s právnikom, ten niekedy rieši podmnožinu úloh programátora, keď píše zmluvu a musí si dať pozor, aby boli pokryté a definované všetky možné stavy, ktoré môžu nastať (keď sa nejaké podmienky neplnia tak, ako to bolo dané v happy scenári).
-
je to len skladacka. na spodku mas 1 bit. s toho mas bit sequencie zvane tiez vektory, prirodzene big cisla alebo ludovo subory. potom je taky trik predstav premennu ako aritmeticky vektor (v ose x), a logicky vektor (v ose y). nad aritmetickou premennou robis plus krat deleno, nad logickou prem. robis bitwise a posuny. potom mas bit funkcie, tych je zas exponencialne viacej z n-bit inputmi ako n-bit cisel. takze je tam kopu priestoru kde mozes hladat tie riesenia a realizovat sa.
na nizkej urovni mas abstrakciu turingov stroj. implementacia toho je operacny system (kazdy bezny os to tak ma). policka na paske turingovho stroja su tie 4KB stranky (virtualna pamat). tie pasky potom putuju cez potrubia internetu a na druhej strane prijemca ich cita a tak dalej.
proceduralna paradigma je klasika, proste turing.stroj na vysokej urovni, oop fajn na enkapsulaciu ale inak proceduralne v ruzovom, funkc. fajn na srandu ale zivot je prave o side effectoch
po tom mas tie trendy (nastroje, jazyky, technologie). programatori nerozhoduju ktory trend bude popularny. user je svedkom cool web blbosti, super 3d srandy. user sa spyta na akej technologii funguje tato blbost, odpoved je angularjs, webgl, na zaklade toho useri sformuju poziadavky na najatie angularjs, webgl programatorov kvoli vytvoreniu podobnych blbosti ako ta uspesna.
programatori proste len nasleduju dopyt tychto userov. ale na spodku je furt to iste, logika, aritmetika, os, potrubia na prenos udajov a to cele visi na elektronike.
-
na funkciach neni nic extra su to len funkcne tabulky. kto zaplati tomu to trochu optimalizujes, kto nezaplati tomu to nechas pomale a odporucis kupu viacerych masin
-
Programátor musí umět myslet jako stroj, dobře to ilustruje tento vtip:
Žena posílá manžela programátora na nákup: “Kup dvě nožičky klobásy a když budou mít vajíčka, kup jich deset.” Muž jde na nákup: “Máte vajíčka?” “Ano.” “Tak mi dejte deset nožiček klobásy.”
12 :-)
-
Ten výtah je zrovna pěkný příklad programátorského myšlení. Hned se tu začaly řešit proměnné a další serepetičky, přitom stačí pár relátek a funguje to úplně stejně ;D
Naopak Airbus není dobrý příklad, ale nikoliv vinou programátora. Tři příklady:
- Pilot chtěl při nízké rychlosti začít stoupat, dal plný tah a přitáhl řízení k sobě, ale počítač usoudil že pro stoupání je potřeba nejdřív nabrat rychlost, a aby toho dosáhl co nedřív, sklopil čumák dolů, kde byl kopec a les.
- Pilot chtěl zrychlit klesání aby nepřeletěl letiště, ale potlačil řízení příliš rychle, počítač to vyhodnotil jako stav nouze a nastavil dvounásobnou výchylku výškovky. Pilotovi o tom nedal nijak vědět a ten ve tmě neviděl že je nad kopcem.
- Pilot chtěl provést manévr, už si přesně nepamatuji jaký, ale počítači se zdál nebezpečný a neudělal vůbec nic. Letadlo spadlo.
Výsledek byly tři rozbité Airbusy a tři hromady mrtvol. Přitom ve všech případech jednal počítač (program!) správně, dokonce podle nejlepších úmyslů, přesto způsobil havárii. Kdyby ta letadla nebyla řízená počítačem, nedošlo by k tomu.
-
Další ilustrační vtípeček: Kouká pesimista na skleničku a řiká si jak je smutně poloprázdná. Kouká na ní optimista a řiká si, jak je vesele poloplná. Pak přijde programátor a řiká si "Safra, proč je ta sklenka 2x větší než je potřeba...?"
-
Bohužel neuvádíte žádné podrobné informace, ale zkusím odhadnout, které lety jste měl na mysli. Vaše popisy vypadají jako ze seriálu Mayday, který má tendence to přehnaně dramatizovat.
Pilot chtěl při nízké rychlosti začít stoupat, dal plný tah a přitáhl řízení k sobě, ale počítač usoudil že pro stoupání je potřeba nejdřív nabrat rychlost, a aby toho dosáhl co nedřív, sklopil čumák dolů, kde byl kopec a les.
Air France 296. Pilot prý přidal, ale letadlo nereagovalo. Ve skutečnosti (podle záznamů, které se bez vědomí pilota přenášely i přes rádio) pilot přidal až ve chvíli, kdy byl pouhých 30 stop nad terénem, a motorům trvá několik sekund, než dostatečně zvýší výkon. V tu dobu už ale letadlo škrtalo stromy.
Pilot chtěl zrychlit klesání aby nepřeletěl letiště, ale potlačil řízení příliš rychle, počítač to vyhodnotil jako stav nouze a nastavil dvounásobnou výchylku výškovky. Pilotovi o tom nedal nijak vědět a ten ve tmě neviděl že je nad kopcem.
Nejspíš Air Inter 148. Pád způsobilo několik faktorů: příliš vysoká rychlost při přibližování (kvůli snaze být rychlejší než TGV), špatné informace o poloze letadla vůči ranveji od věže (tj. piloti si mysleli, že jsou jinde a terén pod nimi je mnohem níž), chybějící GPWS (varování před blízkým terénem) a hlavně to, že piloti zaměnili rychlost klesání a úhel klesání (tedy klesali výrazně rychleji). Letadlo při simulacích netrefilo terén, dokud do simulace nepřidali turbulence, na které autopilot reaguje trochu větším klesáním (stejně jako by to udělal lidský pilot či autopilot od Boeingu, aby zabránili možnosti stallu).
Pilot chtěl provést manévr, už si přesně nepamatuji jaký, ale počítači se zdál nebezpečný a neudělal vůbec nic. Letadlo spadlo.
To vůbec netuším, co by mělo být. Možná TAM 3054? Tam to bylo způsobeno tím, že letadlo umožňovalo nastavit pro každý motor jiný směr tahu, tedy počítač do toho naopak vůbec nekecal. Nebo XL 888T? Tam došlo k chybě při údržbě, kdy zamrzla voda v senzorech, kvůli které selhala právě testovaná detekce nadměrného úhlu náběhu (stall), aniž by si posádka všimla, že se dostala do stallu. Nebo Air France 447? Tam se vypínalo varování před stallem, když byly hodnoty tak extrémní, že se počítač domníval, že jsou vadné senzory, což možná zmátlo pilota.
-
kdyz jsme u toho Mayday, tak letadla maji nejaky ILS - za letu si kolem sebe vytvari nejaky trirozmerny prostor do nejake vzdalenosti a vcas varuje pilota pred letadlem na koliznim kurzu - to muselo byt take hezke programovani ...
to same navadeni na pristani pokud je letiste vybavene prislusnou moderni technikou je uz plne v rezii pocitace ?
treba mne prekvapuje ze dosud neni pro piloty zajisteno "nocni videni, videni skrz mlhu" a stale se operuje s "dohlednosti", ostatne to videni v mlze by se hodilo i ridicum automobilu
za posledni dobu jako nejvetsi hmatatelne produkty vedy v realnem svete povazuju mobily, drony a uz nastupujici autonomni automobily
a pral bych si aby se zvladla termojaderna fuze (zkrotit vodikovou bombu), to by lidstvu prineslo energii za hubicku a asi dost zmenilo pomery sil "na bojisti"
-
... To je něco, čeho nejsou například věřící lidé schopni - zbavit se v okamžiku víry, i když je jim ukázána logická chyba. ...
:o
CO má víra společného s logikou?
(já tu vidím nepochopení reálného života)
-
CO má víra společného s logikou?
(já tu vidím nepochopení reálného života)
Hodně :) Tak třeba dnešní průměrný "programátor" webů je věřící člověk, nemá šajn co se v počítači přesně děje a tak se řídí vírou v soubor pravidel a postupů ne nepodobných náboženství :)
-
Vy se z toho elitářství jednou poserete. Programuju přes polovinu života, prošel jsem si od basicu přes pascal a céčko až k webovým aplikacím, které dělám, protože to dneska prostě sype. Podle trolla Aloise jsem ale retard, co má v židli vyříznutou díru, protože kvůli nízkému IQ neudrží moč a stolici, o programování neví v podstatě nic a za každým enterem vykřikne haleluja. Přitom jsem nejspíš první program napsal, když on ještě říkal hovnu koko. Ale klidně si dál hoňte ega, to je stejně tak všechno, co s tím naděláte.
-
prošel jsem si od basicu přes pascal a céčko až k webovým aplikacím
Nepochopil jste to, Vás se to netýká.
-
kdyz jsme u toho Mayday, tak letadla maji nejaky ILS - za letu si kolem sebe vytvari nejaky trirozmerny prostor do nejake vzdalenosti a vcas varuje pilota pred letadlem na koliznim kurzu - to muselo byt take hezke programovani ...
To není tak těžké. Stačí umět numericky řešit diferenciální rovnice.
to same navadeni na pristani pokud je letiste vybavene prislusnou moderni technikou je uz plne v rezii pocitace ?
Totéž. Jen je potřeba do toho systému zanést externí hodnoty, jako např. stav počasí na letišti. Pokud jsou signály z čidel v pořádku, letadlo přistane samo i za nulové viditelnosti. Piloti však obvykle dělají poloautomatické přistání, aby nevyšli ze cviku a také aby se nenudili.
treba mne prekvapuje ze dosud neni pro piloty zajisteno "nocni videni, videni skrz mlhu" a stale se operuje s "dohlednosti", ostatne to videni v mlze by se hodilo i ridicum automobilu
Piloti to nepotřebují, viz výše. Přistávací radar je užitečnější. Řidičům automobilů by se vidění v mlze jistě hodilo.
-
kdyz jsme u toho Mayday, tak letadla maji nejaky ILS - za letu si kolem sebe vytvari nejaky trirozmerny prostor do nejake vzdalenosti a vcas varuje pilota pred letadlem na koliznim kurzu - to muselo byt take hezke programovani ...
To je v podstatě detekce kolizí z počítačových her :)
treba mne prekvapuje ze dosud neni pro piloty zajisteno "nocni videni, videni skrz mlhu" a stale se operuje s "dohlednosti", ostatne to videni v mlze by se hodilo i ridicum automobilu
Moderní velká letadla dokáží přistát sama a piloti umí přistávat jen na přístroje. Ale pořád se operuje s tím, že při neočekávané události mohou přístroje selhat a letadlo nepočká na lepší počasí.
Problém není to dát do auta, některá auta to i mají (resp. měla to S Klasse). Problém je, že to vypadá jinak, než když to vidíte ve spektru viditelného světla, a tak to vyžaduje výcvik, aby řidič dokázal poznat, co ten obraz v IR (či radarovém, pokud by se použil ten) vidění vlastně je a jak má reagovat. Mnohem užitečnější se ukazují automatické systémy předcházení kolize, které nemají problém poznat, co se děje, a auto zastavit, aniž by se řidič musel cokoliv učit (nová S Klasse).
-
kdyz jsme u toho Mayday, tak letadla maji nejaky ILS - za letu si kolem sebe vytvari nejaky trirozmerny prostor do nejake vzdalenosti a vcas varuje pilota pred letadlem na koliznim kurzu - to muselo byt take hezke programovani ...
To je v podstatě detekce kolizí z počítačových her :)
To by bylo poněud pozdě, nemyslíš? Ten přístroj nemá kolizi detekovat, ale má před ní s předstihem varovat a sjednat nápravu.
-
kdyz jsme u toho Mayday, tak letadla maji nejaky ILS - za letu si kolem sebe vytvari nejaky trirozmerny prostor do nejake vzdalenosti a vcas varuje pilota pred letadlem na koliznim kurzu - to muselo byt take hezke programovani ...
To je v podstatě detekce kolizí z počítačových her :)
To by bylo poněud pozdě, nemyslíš? Ten přístroj nemá kolizi detekovat, ale má před ní s předstihem varovat a sjednat nápravu.
Což jenom znamená, že detekuje kolizi, pokud promítne následujících několik desítek sekund/minut při stabilním kurzu (stejně se ve hrách počítají kolize při střelbě). Sjednání nápravy ty jednodušší systémy (GPWS) buď nedělají, to má udělat pilot, nebo dělají jednoduché kroky (zvýšení tahu a stoupání).
-
To by bylo poněud pozdě, nemyslíš? Ten přístroj nemá kolizi detekovat, ale má před ní s předstihem varovat a sjednat nápravu.
Což jenom znamená, že detekuje kolizi, pokud promítne následujících několik desítek sekund/minut při stabilním kurzu (stejně se ve hrách počítají kolize při střelbě). Sjednání nápravy ty jednodušší systémy (GPWS) buď nedělají, to má udělat pilot, nebo dělají jednoduché kroky (zvýšení tahu a stoupání).
Takže už jsi zohlednil první derivaci, ale je nutné zahrnout přinejmenším i druhou derivaci.
Jeden stroj dostane povel pro stoupání, druhý pro klesání. Tyto povely mají přednost před pokyny operátorů z řídicí věže.
-
Takže už jsi zohlednil první derivaci, ale je nutné zahrnout přinejmenším i druhou derivaci.
Já bych nezapomněl pro jistotu ani na třetí derivaci, možná by to ale chtělo i čtyřapůltou, tam si ale nejsem jist, leda by Krčmářova kobyla nechodila do hospody.
-
A bylo to vtipne v tom, ze jsme se s uzivatelem neshodli na terminu "cisty"
Protoze pojmy jako "cisty" ci "prasarna" jsou (v danem kontextu) vyrazne emocionalne nabite, a do znacne miry iracionalni. Vyjadruji prevazne osobni preferenci mluvciho a temer nic nevypovidaji o objektivni realite.
-
A bylo to vtipne v tom, ze jsme se s uzivatelem neshodli na terminu "cisty"
Protoze pojmy jako "cisty" ci "prasarna" jsou (v danem kontextu) vyrazne emocionalne nabite, a do znacne miry iracionalni. Vyjadruji prevazne osobni preferenci mluvciho a temer nic nevypovidaji o objektivni realite.
Existuje kontext kde se nejedná o emociálně nabyté pojmy? Možná ve vepříně...
-
Na pozadí existují programovací paradigmata. Třeba programátor v Javě se snadno naučí (OOP část) C++ či Python, protože tyhle jazyky mají stejné paradigma, ale takový Haskell (či šablony v C++) se bude učit poměrně dlouho, pokud se vůbec dokáže oprostit od jím zažitého paradigmatu.
Jak kdo, starší třeba začínali s rekurzí v Pascalu, pak rekurze byla out, nyní zase jde do módy. Ale třeba za neúspěchem dříve slibné technologie XSLT je jednoznačně funkcionální paradigma.
-
Odpovím jednoduše, programátor analyzuje svět bez ohledu na své preference, vidí ho takový jaký je, je schopen uvažovat i o aspektech reality, která jemu nevyhovuje. Většina lidí považuje za nesmysl vše, co jim nevyhovuje, nejsou schopni se z této ulity dostat. Programátor si při své práci, tento luxus nemůže dovolit, musí se na svět dívat s nadhledem.
-
Ale třeba za neúspěchem dříve slibné technologie XSLT je jednoznačně funkcionální paradigma.
Což mě velice mrzí, protože práce s XSLT mě baví pro svoji čistotu. Díky návykům z XSLT jsem přestal používat "else" i v ostatních jazycích a mým programům to vyloženě prospělo.
-
Ten výtah je zrovna pěkný příklad programátorského myšlení. Hned se tu začaly řešit proměnné a další serepetičky, přitom stačí pár relátek a funguje to úplně stejně ;D
Naopak Airbus není dobrý příklad, ale nikoliv vinou programátora. Tři příklady:
- Pilot chtěl při nízké rychlosti začít stoupat, dal plný tah a přitáhl řízení k sobě, ale počítač usoudil že pro stoupání je potřeba nejdřív nabrat rychlost, a aby toho dosáhl co nedřív, sklopil čumák dolů, kde byl kopec a les.
- Pilot chtěl zrychlit klesání aby nepřeletěl letiště, ale potlačil řízení příliš rychle, počítač to vyhodnotil jako stav nouze a nastavil dvounásobnou výchylku výškovky. Pilotovi o tom nedal nijak vědět a ten ve tmě neviděl že je nad kopcem.
- Pilot chtěl provést manévr, už si přesně nepamatuji jaký, ale počítači se zdál nebezpečný a neudělal vůbec nic. Letadlo spadlo.
Výsledek byly tři rozbité Airbusy a tři hromady mrtvol. Přitom ve všech případech jednal počítač (program!) správně, dokonce podle nejlepších úmyslů, přesto způsobil havárii. Kdyby ta letadla nebyla řízená počítačem, nedošlo by k tomu.
ano mate pravdu, nedoslo by k tomu, protoze bez pocitace by to letadlo jen stalo v hangaru
-
filozof a programator jsou docela protihlehle pristupy,
Nejsou. Vyšší levely programování se např. skrze logiku a vytváření modelů parádně potkávají nejenom s moderní analytickou filosofií, ale třeba i s některými partiemi dávné filosofie. Dobře zhuštěné seznámení s Aristotelem by pro žádného programátora nebylo na škodu. Každý programátor pořád dokola řeší problémy typu obecné vs. konkrétní, dokonce i substance vs. akcident, akorátže neví, že se tomu tak říká a že se jeho problémy (v trochu jiné podobě samozřejmě) řešily už před dvěma tisíci lety. Jestliže mu někdo na střední nezáživně a nevýstižně vykládal o sporu o univerzálie, zbytečně je odsouzen část z omylů opakovat, jako třeba když si myslí, že nutně musí existovat něco jako třída (~ substance), jinak se svět propadne v chaos :)
Spíš než v tom, o čem píšeš, je problém s lidma, kteří o filosofii nic neví a představují si, že filosofie = bezbřehé nekontrolovatelné a neověřitelné plkání o πčovinách. To není pravda, aspoň ne obecně.
Speciální případ přesahu mezi programováním, filosofií a (matematickou) logikou jsou pak věci jako teorie typů, kategorií, sémantika apod. kde je to úplně zřejmé.
kupodivu dost programatoru ma tandence podivne filozofovat, nastesti vetsina filozofu neprogramuje
...s důrazem na slovo "podivně". Protože je málo lidí, kteří by opravdu rozuměli obojímu a nepouštěli se tímpádem do pouťových taškařic. U nás je tou výjimkou např. prof. Jan Sokol.
-
Ale třeba za neúspěchem dříve slibné technologie XSLT je jednoznačně funkcionální paradigma.
Funkcionální paradigma bez funkcí, to je majstrštyk! ;)
Ve skutečnosti to, co dělá XSLT obtížně použitelným pro "normální" lidi, je to, že to vlastně není nic jiného než jeden gigantický pattern matching - celou vstupní datovou strukturu se snažím namatchovat na jinou strukturu, která definuje výstup. A to není způsob, jakým by se v normálním FP programovalo. Proto taky FP jako takové nemůže být tou příčinou neoblíbenosti (pokud tam teda o nějakém FP vůbec má smysl mluvit).
-
Air France 296,
To je přesně on, akorát že závěry oficiálního vyšetřování byly poněkud neúplné. Zkušenosti dalších pilotů později potvrdily to co pilot říkal od začátku, že Airbus místo stoupání začal klesat. Po přidání plynu a přitažení řízení totiž počítač snížil úhel náběhu, aby nabral rychlost co nejdříve. To je sice to nejlepší co mohl udělat a udělala by to i většina pilotů v jiné situaci, jenže to způsobí počáteční ztrátu výšky, což je poněkud nevhodné když se proti oknu žene kopec.
Nejspíš Air Inter 148.
Tohle je jiný případ, tady byl problém v nevhodném zobrazení hodnot na displeji. To co myslím já ale proběho podobně, s tím že počítač na rychlý pohyb řízení reagoval jako na dvounásobnou výchylku. Asi jako by auto při rychlém cuknutí volantem natočilo kola do plného rejdu, i když řidič cuknul jenom o kousek. A při nulové viditelnosti pilot nestihl zjistit že se to letadlo sklonilo víc než chtěl.
Možná TAM 3054?
Fakt netuším, počítač se prostě vykašlal na to co chtěl pilot a letěl dál podle svého, protože on tomu přece rozumí lépe než omylný člověk. Ale nic bližšího už si nevzpomenu.
ano mate pravdu, nedoslo by k tomu, protoze bez pocitace by to letadlo jen stalo v hangaru
Ten Airbus možná, ale velká dopravní letadla před ním létala padesát let bez počítačů a šlo to. Dokonce nadzvukově. A desítky let se počítače nepoužívaly ani při konstrukci letadel, neuvěřitelné, žejo ;D
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
-
Ale třeba za neúspěchem dříve slibné technologie XSLT je jednoznačně funkcionální paradigma.
Funkcionální paradigma bez funkcí, to je majstrštyk! ;)
Ve skutečnosti to, co dělá XSLT obtížně použitelným pro "normální" lidi, je to, že to vlastně není nic jiného než jeden gigantický pattern matching - celou vstupní datovou strukturu se snažím namatchovat na jinou strukturu, která definuje výstup. A to není způsob, jakým by se v normálním FP programovalo. Proto taky FP jako takové nemůže být tou příčinou neoblíbenosti (pokud tam teda o nějakém FP vůbec má smysl mluvit).
Funkce v XSLT je tag xsl:template.
-
Funkce v XSLT je tag xsl:template.
Což není 1st class citizen.
-
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
Analogové počítače jsou super. Jednoduché, funkční a nemusí se řešit nějaký kmitočet procesoru, protože vše běží v reálném čase.
-
Funkce v XSLT je tag xsl:template.
Což není 1st class citizen.
Z hlediska možných výrazových prostředků k zachycení algoritmu je XSLT téměř ekvivalentní s FP
-
Z hlediska možných výrazových prostředků k zachycení algoritmu je XSLT téměř ekvivalentní s FP
To je klidně možný, ale to už jsme se dost posunuli od tvrzení "XSLT neuspělo a může za to jeho FP povaha", žejo :) Já mám za to, že XSLT neuspělo, protože prostě prase aby se v něm vyznalo.
Nejde o mentální cvičení na téma (ne)ekvivalentnosti jazyků*, ale o to, že když si napíšu výpočet faktoriálu v Haskellu nebo Elixiru, je to krásný, čistý, čitelný a srozumitelný kus kódu, zatímco kdybych si to nedejmatkopřírodo napsal v XSLT, bude to vypadat jako kočičí blití po hodně špatných granulích.
* jak ji definovat, když všechny v úvahu připadající jsou turing complete? V XSLT si zjevně můžu klidně napsat překladač Haskellu, čili ano, "je to ekvivalentní", ale kdo by to propánajána dělal?!
-
Z hlediska možných výrazových prostředků k zachycení algoritmu je XSLT téměř ekvivalentní s FP
To je klidně možný, ale to už jsme se dost posunuli od tvrzení "XSLT neuspělo a může za to jeho FP povaha", žejo :) Já mám za to, že XSLT neuspělo, protože prostě prase aby se v něm vyznalo.
Nejde o mentální cvičení na téma (ne)ekvivalentnosti jazyků*, ale o to, že když si napíšu výpočet faktoriálu v Haskellu nebo Elixiru, je to krásný, čistý, čitelný a srozumitelný kus kódu, zatímco kdybych si to nedejmatkopřírodo napsal v XSLT, bude to vypadat jako kočičí blití po hodně špatných granulích.
* jak ji definovat, když všechny v úvahu připadající jsou turing complete? V XSLT si zjevně můžu klidně napsat překladač Haskellu, čili ano, "je to ekvivalentní", ale kdo by to propánajána dělal?!
Nikoliv, i v Haskelu je to stejné jako v tom xslt, krásné jsou jen školní příklady, praxe je odpudivá. Podívejte se jen, co se dělalo a dělá v javascriptu, aby se potlačila jeho funkcionální povaha, jaké ohavné konstrukce a ornamenty.
ano fp má význam tam kde platí Gatesova teze, běží-li váš program pomalu, kupte si rychlejší počítač, tedy v multiprocesorovém prostředí, kdy efektivitu výpočtu zajišťuje výhradně železo a na úrovni jazyka je preferována čitelnost, nad efektivitou. Jinak ale deklarativní styl programování vede na horší udržovatelnost programu, protože daní za hutnost výrazových prostředků je používání mnoha jen málo modifikovaných frází, takže když něco musíte změnit, je to nutné měnit na mnoha místech a které je obtížné i vyhledat. Extrémním příkladem neefektivity tohoto druhu jsou css styly.
Lambda výrazy jsou pak novodobé goto, snadno se použijí a proto se nevytvoří jedna funkce, která se použije vícekrát, ale lambda výraz, pro každé použití trochu jiný.
-
Podívejte se jen, co se dělalo a dělá v javascriptu, aby se potlačila jeho funkcionální povaha, jaké ohavné konstrukce a ornamenty.
Ajo, ty seš tendle typ :) Tak jo, tak já už tenhle OT asi rozvíjet nebudu, vidím, že to je past na medvědy :))
-
Nikoliv, i v Haskelu je to stejné jako v tom xslt, krásné jsou jen školní příklady, praxe je odpudivá. Podívejte se jen, co se dělalo a dělá v javascriptu, aby se potlačila jeho funkcionální povaha, jaké ohavné konstrukce a ornamenty.
I to XSLT může vypadat hezky, dokonce i v praktickém provedení. Je to jako s každým jazykem: Po někom se to číst dá a po někom ne.
Jinak ale deklarativní styl programování vede na horší udržovatelnost programu, protože daní za hutnost výrazových prostředků je používání mnoha jen málo modifikovaných frází, takže když něco musíte změnit, je to nutné měnit na mnoha místech a které je obtížné i vyhledat.
Ale houby. XSLT se dá psát normálně kulturně a s dodržováním DRY.
Extrémním příkladem neefektivity tohoto druhu jsou css styly.
Další hloupost. Někdo prostě CSS pochopil a někdo ne. Ten, který to nepochopil, mívá CSS i několikrát delší než HTML, ke kterému patří. Prostě nepochopil, že "C" znamená "cascade".
Lambda výrazy jsou pak novodobé goto, snadno se použijí a proto se nevytvoří jedna funkce, která se použije vícekrát, ale lambda výraz, pro každé použití trochu jiný.
Opět hloupost. Lambda výraz nemá s goto nic společného. Používá se tam, kde by bylo nevhodné deklarovat funkci pro jedno použití jinde než v místě toho užití nebo ji chceme předávat jako parametr jiné funkce. Pokud někdo porušuje DRY, není to vinou lambda výrazů, ale jeho neschopnosti.
Pokud je ten lambda výraz pokaždé jiný, je to v pořádku. Nechceme přece psát funkce plné ifů a switchů jen proto, abychom místo tří specializovaných funkcí napsali jednu univerzální s dalším parametrem pro switch. To je cesta do pekel.
-
A bylo to vtipne v tom, ze jsme se s uzivatelem neshodli na terminu "cisty"
Protoze pojmy jako "cisty" ci "prasarna" jsou (v danem kontextu) vyrazne emocionalne nabite, a do znacne miry iracionalni. Vyjadruji prevazne osobni preferenci mluvciho a temer nic nevypovidaji o objektivni realite.
Existuje kontext kde se nejedná o emociálně nabyté pojmy? Možná ve vepříně...
U toho prvniho slova treba v uklidovych sluzbach, druhe jsem uvedl uz jen pro dokresleni...
-
Nikoliv, i v Haskelu je to stejné jako v tom xslt, krásné jsou jen školní příklady, praxe je odpudivá. Podívejte se jen, co se dělalo a dělá v javascriptu, aby se potlačila jeho funkcionální povaha, jaké ohavné konstrukce a ornamenty.
I to XSLT může vypadat hezky, dokonce i v praktickém provedení. Je to jako s každým jazykem: Po někom se to číst dá a po někom ne.
Jinak ale deklarativní styl programování vede na horší udržovatelnost programu, protože daní za hutnost výrazových prostředků je používání mnoha jen málo modifikovaných frází, takže když něco musíte změnit, je to nutné měnit na mnoha místech a které je obtížné i vyhledat.
Ale houby. XSLT se dá psát normálně kulturně a s dodržováním DRY.
Extrémním příkladem neefektivity tohoto druhu jsou css styly.
Další hloupost. Někdo prostě CSS pochopil a někdo ne. Ten, který to nepochopil, mívá CSS i několikrát delší než HTML, ke kterému patří. Prostě nepochopil, že "C" znamená "cascade".
Lambda výrazy jsou pak novodobé goto, snadno se použijí a proto se nevytvoří jedna funkce, která se použije vícekrát, ale lambda výraz, pro každé použití trochu jiný.
Opět hloupost. Lambda výraz nemá s goto nic společného. Používá se tam, kde by bylo nevhodné deklarovat funkci pro jedno použití jinde než v místě toho užití nebo ji chceme předávat jako parametr jiné funkce. Pokud někdo porušuje DRY, není to vinou lambda výrazů, ale jeho neschopnosti.
Pokud je ten lambda výraz pokaždé jiný, je to v pořádku. Nechceme přece psát funkce plné ifů a switchů jen proto, abychom místo tří specializovaných funkcí napsali jednu univerzální s dalším parametrem pro switch. To je cesta do pekel.
Může, ale téměř nikdo to nedělá, a taky nepočítáte s tím, co udělá s programem údržba.
Goto lze taky používat rozumně, ale svádí k tomu usnadnit si práci s návrhem. Totéž lambda výrazy. Totéž css. Není třeba psát univerzální funkce, ale krátké funkce a mít problém dobře logicky strukturovaný. Funkce oproti lambda příkazu má tu výhodu, že vznikne pojmenovaný kus kódu, který lze na jednom místě změnit, aby došlo ke změně chování všude. To lambda výrazy nesplňují, naopak plní funkci špatně použitého goto. Tam kde se vám nechce vymyslet výstižné pojmenování, tam prásknete lambda funkci, nemáte-li pojmenování, znamená to, že vlastně nemáte dobře promyšlené co děláte a lambda funkcí jste si jen usnadnil práci a často zprasil návrh.
Add css, kdyby to byla pravda, tak by nikdo neexperimentoval s LESS a nikdo by se nesnažil do javascriptu zavádět klasické třídy.
určitě je lepší než napsat:
red_cars = map(lambda x: x.color = 'red', filter(lambda x: x.id == 'ID2376', cars))
je lepší napsat
def set_color(color):
return lambda x: x.color = color
def where_id(id):
return lambda x: x.id == id
car.id = 'ID2376'
red_cars = map(set_color('red'), filter(where_id(car), cars)
protože pak můžete v budoucnosti vylepšit vyhledávání pomocí regulárního výrazu, nebo strukturovat data různých entit a typů podle jednotné šablony, obsahující id, barvu a podobně.
-
určitě je lepší než napsat:
red_cars = map(lambda x: x.color = 'red', filter(lambda x: x.id == 'ID2376', cars))
je lepší napsat
def set_color(color):
return lambda x: x.color = color
def where_id(id):
return lambda x: x.id == id
car.id = 'ID2376'
red_cars = map(set_color('red'), filter(where_id(car), cars)
protože pak můžete v budoucnosti vylepšit vyhledávání pomocí regulárního výrazu, nebo strukturovat data různých entit a typů podle jednotné šablony, obsahující id, barvu a podobně.
Ufff... Já se jenom zeptám: jaké funkcionální jazyky umíš a kolik jsi toho v nich naprogramoval? Nemůžu se totiž ubránit dojmu, že si myslíš, že JS je funkcionální jazyk a je hnusný, protože se v něm používají funkcionální patterny. Jediný, co z toho je pravda, je, že JS je hnusný jazyk. A shodnou se na tom úplně všichni.
Myslím si to, protože 1. mluvíš o objektech, které se ve FP nepoužívají, 2. v JS jsou samozřejmě lambdy nadužívané, ale má to jiný důvod než snahu o FP
Ten hlavní důvod, proč se v JS lambdy nadužívají, je, že neumí synchronizovat asynchronní události. Takže v JS musím napsat:
function set_user_val(callback) {
async_get_data(function(data){
some_other_async(data,callback)
})
}
set_user_val(function(data){
$('#user-val').value(data['user_val'])
})
...a ES6 to vylepší jenom tím, že nemusím psát "function", ale jinak ten kód zůstane stejně pitomě vnořený a plný lambd. V pořádném funkcionálním jazyce, který umí synchronizovat asynchronní události by to mohlo vypadat třeba takhle (Elixir):
def get_data do
send(Agent1, :get_data)
data = receive do
{:get_data_response,data} -> data #### TADY
after 5000 -> raise "Timeout"
end
end
data = get_data |> some_other_async
set_value('#user-val',data)
end
...a nepotřeboval jsem jedinou lambdu. Na řádku "TADY" dochází k tomu, že funkce normálně synchronně vrací hodnotu, kterou získala asynchronně. To v JS nejde a proto je potřeba donekonečna vnořovat callbacky nebo aspoň řetězit berličky typu
.done(()=>{...}).fail(()=>{...})
Jinak, i ten filtr je v Elixiru daleko čitelnější:
red_cars = cars |> Enum.filter(fn x -> x[:id]==XXXX end) |> Enum.map(fn x -> x[:color]=:red end)
nebo ještě zhuštěněji:
red_cars = cars |> Enum.filter(&(&1[:id]==XXXX)) |> Enum.map(&(&1[:color]=:red))
-
Errata:
x[:color]=:red
Má být samozřejmě Map.put(x,:color,:red).
P.S. A jestli tě trápí lambdy v Pythonu, tak tam je to podobně - synchronizace tam sice udělat jde ale taky krkolomně, a knihovny typu asyncio se násilně snaží do jazyka dostat něco, na co nebyl navržený. Jsou to prostě sprosté zamykací jednovláknové jazyky a ohýbat je na něco jinýho vždycky bolí...
-
Já dodnes nechápu, proč lidé vždy obhajují svůj milovaný jazyk a snaží se ho použít i za cenu krkolomného ohýbání na všehny tipi úloh, já k jazykům přistupuji jako k nástrojům, každý je jiný a byl nějak navržen a podle oblasti na kterou byl navržen jej používám, proč to proboha nehce nikdo pochopit. Šroubovákem hřebík po chvíli také zatlučete, ale kladivem to jde líp a obráceně šroubovák se hodí na zašroubování šroubu lépe než kladivo.
Asi je to v lenosti naučit se pár příkazů v něčem jiném.
Něž přišli více jádrové procesory byl paralelismus v podstatě jen takové slovo do pranice a podle toho sou ty jazyky navrženy dělat něco asynchroně bylo v podstatě jen hezké buzzword realita byla jinaá naopak se tím často výkon stratil. Dneska je jiná doba a pro paralelní programování jsou speciálně navržené jazyky kde se výrobou nového threadu neupíšete k smrti ale rovnou se o to za vás postará kompilátor. Občas se zapomíná na to že pracovat má počítač a vy mu jako programátor máte říkat jen co má dělat ne dělat práci za něj.
Druhá stánka mince je, že se z části programování stalo řemeslo.
A ještě skvost dnešní doby kdy už vznikají freamworky nad freamworky aby se stím lépe dělalo.
sorry za hrubky
-
Ale třeba za neúspěchem dříve slibné technologie XSLT je jednoznačně funkcionální paradigma.
Funkcionální paradigma bez funkcí, to je majstrštyk! ;)
Ve skutečnosti to, co dělá XSLT obtížně použitelným pro "normální" lidi, je to, že to vlastně není nic jiného než jeden gigantický pattern matching - celou vstupní datovou strukturu se snažím namatchovat na jinou strukturu, která definuje výstup. A to není způsob, jakým by se v normálním FP programovalo. Proto taky FP jako takové nemůže být tou příčinou neoblíbenosti (pokud tam teda o nějakém FP vůbec má smysl mluvit).
Funkce v XSLT je tag xsl:template.
xsl:template není funkce, to je xsl:function.
-
Goto lze taky používat rozumně, ale svádí k tomu usnadnit si práci s návrhem. Totéž lambda výrazy. Totéž css. Není třeba psát univerzální funkce, ale krátké funkce a mít problém dobře logicky strukturovaný. Funkce oproti lambda příkazu má tu výhodu, že vznikne pojmenovaný kus kódu, který lze na jednom místě změnit, aby došlo ke změně chování všude. To lambda výrazy nesplňují, naopak plní funkci špatně použitého goto. Tam kde se vám nechce vymyslet výstižné pojmenování, tam prásknete lambda funkci, nemáte-li pojmenování, znamená to, že vlastně nemáte dobře promyšlené co děláte a lambda funkcí jste si jen usnadnil práci a často zprasil návrh.
Lambda výrazy nemají s goto nic společného.
Lambda výraz lze normálně pojmenovat. Běžně to dělám z důvodu čitelnosti programu - je to lepší, než násilné zalamování kódu na řádku. Nemohu za to, že někdo používá lambda výrazy nevhodným způsobem a že neumí pojmenovávat komponenty programu.
-
Programatoruv pohled na svet je trochu jiny, do jiste miry bych to prirovnal k matematikovi, protoze matematici "vidi defakto vsechny veci v cislech", programator je vidi v elementarnich "krocich". Abych ti to prirovnal, manzelka ti rekne "Bez koupit pivo", pusti se ti v hlave "program" "koupit pivo" a tento program obsahuje "1000 kroku" k tomu, abys ho vykonal. Nebudu uplne presny, ale nastinim zhruba jak by to mohlo vypadat.
1.) najit penize (do je defakto dalsi mikro program/funkce)
2.) vzit si tasku/batoh
3.) najit klice od bytu
4.) najit klice od auta
5.) najit auto =)
6.) nasednout do auta (vykonat program rizeni k obchodaku)
7.) najit v obchodaku basu piv
8.) dotlacit vozik k pokladne
9.) zaplatit
10.) najit auto na parkovisti
11.) nalozit pivo
12.) nasednout do auta (vykonat program rizeni domu)
13.) vyndat pivo z auta
14.) dojit domu
15.) otevrit pivo
16.) vypit pivo
defakto jde o rozebirani jednotlivych cinnosti na elementarni casti, vyse zminene je zjednodusene a nepresne, jelikoz kazdy ten krok se da jeste rozebrat do mensich detailu a casti co je treba vykonat napr. "odemknout dvere, otevrit dvere, zavrit dvere, zamknout ...." a defakto je uplne jedno jestli to pisu cesky, anglicky nebo nemecky nebo indiansky. Snad ti to na tvoje filozofovani bude stacit.
-
Pro upresneni, posledni dva kroky, 15. a 16. jsou vlastne zavadne funkce, ktere nemaji v programu "koupit pivo" co delat, jelikoz koupit neznamena konzumovat .... =)
-
No mně teda pořád ještě praktický Haskell připadá dost pěkný - ve srovnání s čímkoliv jiným.
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ?
Zjistíš, že v 95% příkladů je chyba u tebe. Na druhou stranu zjistíš, že v 5% příkladů je chyba v něčem, čemu jsi absolutně věřil (při jednom projektu jsem našel chyby v gcc a prakticky každém emulátoru, na který jsem šáhnul). Zjistíš, že počítači je jedno, jestli bys chtěl, aby něco nějak fungovalo.
Nevím, jestli je to zrovna programováním, ale myslím, že mám mnohem menší problém změnit názor, když zjistím, že je někde nějaký logický problém. Spousta lidí má tendenci uvažovat stylem "já to tak ale chci, tak si pro to najdu zdůvodnění" - ale počítači je jedno, co chceš, buď je to správně nebo ne. Stejně tak se spousta lidí odvolává na autority - ale autority nic neznamenají. Občas se i autority mýlí - občas ta chyba prostě není u tebe.
Při programování je dost běžné uvažování - tohle neumím, kde je manuál, jdu se to naučit. Dobrý programátor se prostě pořád něco učí. Potřebuju se naučit cizí jazyk? Je to spousta práce, ale jde to. Jinak celé programování je v podstatě o tom, že přesně popíšeš, co chceš vyřešit v pojmech, které již řešit umíš. A dobré programování znamená, že máš dobře ošetřené i různé krajní stavy - takže profesionální deformace je automaticky v čemkoliv hledat limity, kde to přestává fungovat :)
-
Pro upresneni, posledni dva kroky, 15. a 16. jsou vlastne zavadne funkce, ktere nemaji v programu "koupit pivo" co delat, jelikoz koupit neznamena konzumovat .... =)
Což bohužel odpovídá běžné programátorské realitě :-)
-
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
Analogové počítače jsou super. Jednoduché, funkční a nemusí se řešit nějaký kmitočet procesoru, protože vše běží v reálném čase.
dalo by se nejak prirovnat analogove/digitalni *** spojite/diskretni vstupy *** realna/priblizna cisla ?
nekde jsem cetl ze realna cisla (pocitani v nich) je pro panaboha, pro nas bezne smrtelniky vzdy pracujeme pouze s urcitou aproximaci (viz napr. pi atd..), coz je u neketyrch systemu problem, potrebovali bysme na vstup davat realna cisla (napr. deterministicky chaos) priroda v nasich meritkach (ne kvantovka) je asi spis spojita nez diskretni tak by se vic hodily na vstup ty spojite signaly a analogove pocitace ?
-
Programatoruv pohled na svet je trochu jiny, do jiste miry bych to prirovnal k matematikovi, protoze matematici "vidi defakto vsechny veci v cislech", programator je vidi v elementarnich "krocich". Abych ti to prirovnal, manzelka ti rekne "Bez koupit pivo", pusti se ti v hlave "program" "koupit pivo" a tento program obsahuje "1000 kroku" k tomu, abys ho vykonal. Nebudu uplne presny, ale nastinim zhruba jak by to mohlo vypadat.
1.) najit penize (do je defakto dalsi mikro program/funkce)
2.) vzit si tasku/batoh
3.) najit klice od bytu
4.) najit klice od auta
5.) najit auto =)
6.) nasednout do auta (vykonat program rizeni k obchodaku)
7.) najit v obchodaku basu piv
8.) dotlacit vozik k pokladne
9.) zaplatit
10.) najit auto na parkovisti
11.) nalozit pivo
12.) nasednout do auta (vykonat program rizeni domu)
13.) vyndat pivo z auta
14.) dojit domu
15.) otevrit pivo
16.) vypit pivo
defakto jde o rozebirani jednotlivych cinnosti na elementarni casti, vyse zminene je zjednodusene a nepresne, jelikoz kazdy ten krok se da jeste rozebrat do mensich detailu a casti co je treba vykonat napr. "odemknout dvere, otevrit dvere, zavrit dvere, zamknout ...." a defakto je uplne jedno jestli to pisu cesky, anglicky nebo nemecky nebo indiansky. Snad ti to na tvoje filozofovani bude stacit.
Ano, na rozdíl od normálních smrtelníků, kteří uvažují primárně zda je ten který krok pro ně dobrý, pokud se jim zdá, že není, pak pro ně prostě neexistuje. Například krok 1. ne najít peníze, ale jít do práce :-)))
-
Jinak, i ten filtr je v Elixiru daleko čitelnější:
red_cars = cars |> Enum.filter(fn x -> x[:id]==XXXX end) |> Enum.map(fn x -> x[:color]=:red end)
nebo ještě zhuštěněji:
red_cars = cars |> Enum.filter(&(&1[:id]==XXXX)) |> Enum.map(&(&1[:color]=:red))
Dlouhé řádky nejsou čitelné. navíc oproti mému řešení v Pythonu je ve vašem zápisu mnohem více redundandních znaků, například |>, &, u lambda výrazů musíte v hlavě postupně simulovat co dělají, nemůžete s nimi pracovat jako se symbolem, tudíž ztrácíte nadhled nad kontextem. Je ale možné, že někdo je čte jako slova, naskočí mu simulace sama, jako když si přečte slovo jablko, tak uvidí vnitřním zrakem jablko, to ale můj případ není. Zajímalo by mě, zda to někdo takto umí. Je to váš případ?
No a pak přijde zákazník s tím, že potřebuje vyhledávat ne podle id, ale podle regulárního výrazu nad id, u mě to znamená, že upravím jednu funkci, a u vás to znamená, že musíte procházet všechny lambdy v aplikaci, protože někde jste použil jako proměnnou x, jinde třeba id atp., na významově totéž.
-
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
Analogové počítače jsou super. Jednoduché, funkční a nemusí se řešit nějaký kmitočet procesoru, protože vše běží v reálném čase.
dalo by se nejak prirovnat analogove/digitalni *** spojite/diskretni vstupy *** realna/priblizna cisla ?
nekde jsem cetl ze realna cisla (pocitani v nich) je pro panaboha, pro nas bezne smrtelniky vzdy pracujeme pouze s urcitou aproximaci (viz napr. pi atd..), coz je u neketyrch systemu problem, potrebovali bysme na vstup davat realna cisla (napr. deterministicky chaos) priroda v nasich meritkach (ne kvantovka) je asi spis spojita nez diskretni tak by se vic hodily na vstup ty spojite signaly a analogove pocitace ?
Analogové počítače mají jeden problém: Přesnost. Zatímco pro fyzikální výpočet (přistání Concorde, rezonance mostu či nápravy, rozměry komponent výrobku,...) je přesnost 0.1 % naprosto vyhovující, pro jiné už méně a například pro finančnictví totálně nevyhovující (nestačí jim ani real či double u digitálních). Navíc analogové počítače bývají náchylné na rušení (proto se jimi nederivuje, ale integruje).
Digitální počítače pracují s takovou přesností, jakou potřebujeme. Nevyžadují seřízení, stačí je naprogramovat.
-
No mně teda pořád ještě praktický Haskell připadá dost pěkný - ve srovnání s čímkoliv jiným.
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ?
Zjistíš, že v 95% příkladů je chyba u tebe. Na druhou stranu zjistíš, že v 5% příkladů je chyba v něčem, čemu jsi absolutně věřil (při jednom projektu jsem našel chyby v gcc a prakticky každém emulátoru, na který jsem šáhnul). Zjistíš, že počítači je jedno, jestli bys chtěl, aby něco nějak fungovalo.
Nevím, jestli je to zrovna programováním, ale myslím, že mám mnohem menší problém změnit názor, když zjistím, že je někde nějaký logický problém. Spousta lidí má tendenci uvažovat stylem "já to tak ale chci, tak si pro to najdu zdůvodnění" - ale počítači je jedno, co chceš, buď je to správně nebo ne. Stejně tak se spousta lidí odvolává na autority - ale autority nic neznamenají. Občas se i autority mýlí - občas ta chyba prostě není u tebe.
Při programování je dost běžné uvažování - tohle neumím, kde je manuál, jdu se to naučit. Dobrý programátor se prostě pořád něco učí. Potřebuju se naučit cizí jazyk? Je to spousta práce, ale jde to. Jinak celé programování je v podstatě o tom, že přesně popíšeš, co chceš vyřešit v pojmech, které již řešit umíš. A dobré programování znamená, že máš dobře ošetřené i různé krajní stavy - takže profesionální deformace je automaticky v čemkoliv hledat limity, kde to přestává fungovat :)
Bravo, to je nejpřesnější vystižení problému!
-
res = cars & map (set color "red")
& filter (\a -> a ^. id == "xxx")
Me to pripada docela citelny... tu filtraci bych mozna pojmenoval, ale to nastaveni barvy fakt ne. Kratke to je a citelne taky (a ma to byt obracene, ale pisu to na mobilu...)
-
Programatoruv pohled na svet je trochu jiny, do jiste miry bych to prirovnal k matematikovi, protoze matematici "vidi defakto vsechny veci v cislech", programator je vidi v elementarnich "krocich". Abych ti to prirovnal, manzelka ti rekne "Bez koupit pivo", pusti se ti v hlave "program" "koupit pivo" a tento program obsahuje "1000 kroku" k tomu, abys ho vykonal. Nebudu uplne presny, ale nastinim zhruba jak by to mohlo vypadat.
1.) najit penize (do je defakto dalsi mikro program/funkce)
2.) vzit si tasku/batoh
3.) najit klice od bytu
4.) najit klice od auta
5.) najit auto =)
6.) nasednout do auta (vykonat program rizeni k obchodaku)
7.) najit v obchodaku basu piv
8.) dotlacit vozik k pokladne
9.) zaplatit
10.) najit auto na parkovisti
11.) nalozit pivo
12.) nasednout do auta (vykonat program rizeni domu)
13.) vyndat pivo z auta
14.) dojit domu
15.) otevrit pivo
16.) vypit pivo
defakto jde o rozebirani jednotlivych cinnosti na elementarni casti, vyse zminene je zjednodusene a nepresne, jelikoz kazdy ten krok se da jeste rozebrat do mensich detailu a casti co je treba vykonat napr. "odemknout dvere, otevrit dvere, zavrit dvere, zamknout ...." a defakto je uplne jedno jestli to pisu cesky, anglicky nebo nemecky nebo indiansky. Snad ti to na tvoje filozofovani bude stacit.
Ano, na rozdíl od normálních smrtelníků, kteří uvažují primárně zda je ten který krok pro ně dobrý, pokud se jim zdá, že není, pak pro ně prostě neexistuje. Například krok 1. ne najít peníze, ale jít do práce :-)))
hehehe, no asi jsem mel napsat najit penezenku, coz muze byt volne prelozeno jako, rict manzelce :D
-
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
Analogové počítače jsou super. Jednoduché, funkční a nemusí se řešit nějaký kmitočet procesoru, protože vše běží v reálném čase.
dalo by se nejak prirovnat analogove/digitalni *** spojite/diskretni vstupy *** realna/priblizna cisla ?
nekde jsem cetl ze realna cisla (pocitani v nich) je pro panaboha, pro nas bezne smrtelniky vzdy pracujeme pouze s urcitou aproximaci (viz napr. pi atd..), coz je u neketyrch systemu problem, potrebovali bysme na vstup davat realna cisla (napr. deterministicky chaos) priroda v nasich meritkach (ne kvantovka) je asi spis spojita nez diskretni tak by se vic hodily na vstup ty spojite signaly a analogove pocitace ?
Analogový počítač je jako logaritmické pravítko, číslicový jako kuličkové počítadlo.
Když chceš na logaritmickém pravítku vynásobit nebo vydělit dvě čísla, posuneš vůči sobě dvě stupnice, a výsledek máš okamžitě před očima. S přesností na jedno desetinné místo. Pro počítání druhé odmocniny, sinu a kosinu, prostě čehokoliv, máš na něm samostatnou stupnici, a můžeš si pomoci posuvníkem, který ti to například vynásobí číslem Pí. Ale pořád jenom s přesností na jedno desetinné místo, zato okamžitě.
Pro kuličkové počítadlo musíš mít sadu postupů (programů), které opakuješ pořád dokola a dokola, dokud nedosáhneš výsledku s požadovanou přesností. Je to mnohem přesnější, mnohem pracnější, a mnohem pomalejší. Navíc musíš mít pro každou činnost předem nachystaný program, který jí bude provádět.
Příroda se spojitě jenom tváří, ve skutečnosti si s celými čísly úplně vystačí. To jenom omezené lidské myšlení nedokáže obsáhnout přesný počet atomů ve sklenici vody, proto si musí vypomoci umělými makrojednotkami jako je litr, a "reálnými" čísly, popisujícími velmi přibližně celočíselnou realitu. Jako to logaritmické pravítko - nepřesně ale rychle.
Takže je to přesně naopak, přesné počítání s celými čísly je pro pánaboha, lidé si musí vystačit s nepřesnými reálnými. Mimochodem, černé díry jsou místa ve Vesmíru, kde Bůh dělil nulou ;D
-
Ad Radovan, to je tím, že se chybně matematické operace i samotný pojem čísla odvozují od sčítání, fyzikálně reálně jako prvotní operace je dělení a v našem vesmíru je dělení zobrazení do přirozených čísel. Zbytky nevznikají, počítáte-li výsledek na kusy (kvanta).
Jinak pozdravujte MEDU :-)
-
Analogový počítač je jako logaritmické pravítko, číslicový jako kuličkové počítadlo.
To je docela výstižné přirovnání.
Když chceš na logaritmickém pravítku vynásobit nebo vydělit dvě čísla, posuneš vůči sobě dvě stupnice, a výsledek máš okamžitě před očima. S přesností na jedno desetinné místo. Pro počítání druhé odmocniny, sinu a kosinu, prostě čehokoliv, máš na něm samostatnou stupnici, a můžeš si pomoci posuvníkem, který ti to například vynásobí číslem Pí. Ale pořád jenom s přesností na jedno desetinné místo, zato okamžitě.
Ta přesnost na logáru je o hodně lepší než jen jedno desetinné místo. Jinak by mosty na něm počítané asi spadly.
Pro kuličkové počítadlo musíš mít sadu postupů (programů), které opakuješ pořád dokola a dokola, dokud nedosáhneš výsledku s požadovanou přesností. Je to mnohem přesnější, mnohem pracnější, a mnohem pomalejší. Navíc musíš mít pro každou činnost předem nachystaný program, který jí bude provádět.
Jenže jsme se naučili vyrábět počítače, které zmíněné nevýhody eliminují. I obyčejné Arduino by dnes dokázalo přistát na Měsíci lépe než tehdejší počítače. Pomiňme, že se pro tento účel nehodí.
-
Add Kit, navigační počítač Apolla bylo vlastně takové Arduino, byl docela malý a nebyl analogový. Viz zde https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
-
Add Kit
Ja bych Kita nepricital.
-
Add Kit
Ja bych Kita nepricital.
Ha, ha, ha, ... To je moje profesionální deformace.
-
Ten hlavní důvod, proč se v JS lambdy nadužívají, je, že neumí synchronizovat asynchronní události. Takže v JS musím napsat:
function set_user_val(callback) {
async_get_data(function(data){
some_other_async(data,callback)
})
}
set_user_val(function(data){
$('#user-val').value(data['user_val'])
})
...a ES6 to vylepší jenom tím, že nemusím psát "function", ale jinak ten kód zůstane stejně pitomě vnořený a plný lambd. V pořádném funkcionálním jazyce, který umí synchronizovat asynchronní události by to mohlo vypadat třeba takhle (Elixir):
Nějak jsem nepochopil ten tvůj JS kód, zvláště pak proč předávat parametry data a callback do funkce some_other_async, když jsou pro ni dostupné přes závoru.
Pro podporu svých argumentů není potřeba protivníka záměrně potápět... ;)
Taky nesouhlasím s tvým vyjádřením ohledně ES6 (navíc hodně toho jde i v ES5), kromě callbacků můžu použít promises, generátory a async/await (ES7, ale s babelem je to jedno).
S tím souvisí ještě jedna věc.
Asi je to v lenosti naučit se pár příkazů v něčem jiném.
Toto je veliký omyl. Naučit se pár příkazů je záležitost jednoho dne. Ale každý jazyk ma trošku jinou filozofii a komunitu lidí. A proto i tak příbuzné jazyky jako třeba Python, Ruby nebo Javascript jsou z hlubšího pohledu hodně odlišné, existují v nich naprosto odlišné idiomy a přetransformovat se z jednoho na druhý neznamená naučit se pár příkazů, ale porozumět jak v nich programy tvořit, poznat ekosystém, používané knihovny atd. A to je záležitost několika měsíců, minimálně. A poměrně hodně samostudia zdrojových kódů ikonických implementací. A to vůbec nemluvím o filozoficky úplně rozdílných jazycích.
To je důvod, proč např. v node.js neuspěly frameworky napodobující RoR, ale naopak mikrofunkce a mikroframeworky. A celý humbuk okolo microservices z velké čísti pochází z node.js.
Každému si nese svou historickou zátěž a vyhovuje mu něco jiného, proto jsou tak rozdílné názory.
-
Add Kit, navigační počítač Apolla bylo vlastně takové Arduino, byl docela malý a nebyl analogový. Viz zde https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
On toho dohromady moc neuměl. Bral údaje z přistávacího radaru a zderivoval. Obojí zobrazoval na displejích a řídil podle toho i trysku motoru.
Ty displeje jsou numerické, ale kdyby se ty hodnoty zlogaritmovaly, tak by stačily dva analogové měřáky nebo dvě řady ledek.
-
Ad Kit, operační systém uměl multitasking pro osum úloh najednou. Pracoval jste někdy na stroji s feritovou pamětí?
-
Ta přesnost na logáru je o hodně lepší než jen jedno desetinné místo. Jinak by mosty na něm počítané asi spadly.
No, jsou na to finty, ale stupnice na logáru je pořád jenom na to jedno desetinné místo. Správně bych měl říct na dvě číslice, protože to vůbec nemusí být nějaké desetiny ;)
Přesněji se s ním dá počítat také, ale to už zase musíš mít "balík programů" jak to provést, a opakovat je dokola, tím jsme se dostali k hybridním počítačům, což byla vůbec dost divoká kategorie. Ty bych sem radši netahal (vyráběl se i kříženec logára a Addiatoru (https://www.youtube.com/watch?v=Mehig4iLitw)).
S těmi nepřesnými mosty to nebude tak horké, jsou tam bezpečnostní násobky, a navíc:
Co je to pí?
Matematik: Pí je poměr obvodu kruhu a jeho průměru.
Fyzik: Pí je 3.1415927 plus mínus 0.00000005
Inženýr: Pí je něco kolem tří...
Zato budovy WTC už byly projektované pomocí číslicového počítače!
Jenže jsme se naučili vyrábět počítače, které zmíněné nevýhody eliminují. I obyčejné Arduino by dnes dokázalo přistát na Měsíci lépe než tehdejší počítače. Pomiňme, že se pro tento účel nehodí.
Neeliminují, jen to dokážou dělat mnohem rychleji a s větším počtem kuliček najednou. Arduino bych na Měsíc klidně poslal, jenom bych ho pro jistotu obalil pořádným futrálem z olova. Přece jen ty tranzistory a ferity vesmírné záření tak moc nerozhazovalo. Space Shuttle létal s feritovými pamětmi ještě v devadesátých letech!
Ten počítač v Apollu byl úžasné technické dílo, a neuvěřitelně ohackované už z vývoje. Například během projektování zjistili že na nějaký výpočet nestačí, a stáli před volbou jestli do slova přidat jeden bit, nebo z jedné instrukce udělat prefix pro druhou rozšiřující instrukční sadu, tak vybrali tu lehčí variantu - lehčí na hmotnost, těžší na vývoj ;D
Ale přistání se zapnutým radarem nakonec stejně nezvládl, Armstrong to musel vzít do pracek a přistát sám, mezi dvoumetrové šutry. A Aldrin měl sebou logaritmické pravítko na kterém výpočty počítače po celý let kontroloval, protože mu nevěřil.
Když už jsme zase u toho létání, tak letoun Voyager jako první dokázal v roce 1986 obletět zeměkouli bez mezipřistání a tankování. Celý jeho vývoj prováděl Burt Rutan na vlastním Apple II, v programech které si sám napsal v BASICu!
-
Ad Kit, operační systém uměl multitasking pro osum úloh najednou. Pracoval jste někdy na stroji s feritovou pamětí?
Ano, pracoval a tu feritovou desku jsem i držel v ruce. Krásná výšivka :-)
Ten počítač v Apollu byl typu MISD - s jednou sadou registrů pracovalo osm procesů.
-
Ta přesnost na logáru je o hodně lepší než jen jedno desetinné místo. Jinak by mosty na něm počítané asi spadly.
No, jsou na to finty, ale stupnice na logáru je pořád jenom na to jedno desetinné místo. Správně bych měl říct na dvě číslice, protože to vůbec nemusí být nějaké desetiny ;)
Přesněji se s ním dá počítat také, ale to už zase musíš mít "balík programů" jak to provést, a opakovat je dokola, tím jsme se dostali k hybridním počítačům, což byla vůbec dost divoká kategorie. Ty bych sem radši netahal (vyráběl se i kříženec logára a Addiatoru (https://www.youtube.com/watch?v=Mehig4iLitw)).
Ta stupnice mezi jedničkou a dvojkou má dvě desetinná místa, plus další místo se dá odhadnout. Za dvojkou se už odhaduje to druhé desetinné místo, takže na přesnost 0.1 % se to při troše pečlivosti dalo dotáhnout.
Zajímavé na tom logáru je, že se dá násobit a dělit současně, což je neskutečná výhoda.
-
Ta stupnice mezi jedničkou a dvojkou má dvě desetinná místa, plus další místo se dá odhadnout. Za dvojkou se už odhaduje to druhé desetinné místo, takže na přesnost 0.1 % se to při troše pečlivosti dalo dotáhnout.
Zajímavé na tom logáru je, že se dá násobit a dělit současně, což je neskutečná výhoda.
Logára co tu mám (plastová) by byla tak třikrát nepřesnější, možná kromě toho kovového dederonského. 8)
Jo, spočítat plochu kruhu obnáší jeden pohyb posuvníku, a tím je číslo umocněné a navrch ještě vynásobené Pí. Kdybych měl vybrat deset největších vynálezů všech dob, tak by logaritmické pravítko určitě nechybělo, a daleko za kolem a rozděláním ohně by se neumístilo.
-
red_cars = map(lambda x: x.color = 'red', filter(lambda x: x.id == 'ID2376', cars))
Jinak, i ten filtr je v Elixiru daleko čitelnější:
red_cars = cars |> Enum.filter(fn x -> x[:id]==XXXX end) |> Enum.map(fn x -> x[:color]=:red end)
nebo ještě zhuštěněji:
red_cars = cars |> Enum.filter(&(&1[:id]==XXXX)) |> Enum.map(&(&1[:color]=:red))
Prihodim Scala verzi:
val redCars = cars.filter(_.id == "ID2376").map(c => {c.color = "red"; c})
pripadne takto
val redCars = cars filter {_.id == "ID2376"} map { c => c.color = "red"; c }
Kdyz jsem byl donucen psat v Pythonu nejaky ukol do skoly, tak pri srovnani se Scalou jsem si pripadal jak bez rukou. Volani nesla rozumne retezit, nezvykle poradi u operaci nad kolekcemi (mozna o zvyku, nevim), mnoho chybejicich operaci a zapis lambdy byl tak neuveritelne neprakticky uzvaneny.
A teda osobne me prijde meneni stavu v map jako prasecina...
def get_data do
send(Agent1, :get_data)
data = receive do
{:get_data_response,data} -> data #### TADY
after 5000 -> raise "Timeout"
end
end
data = get_data |> some_other_async
set_value('#user-val',data)
end
Zkusil jsem i druhy priklad, ale nevim zda jsem to pochopil spravne (Elixir neznam). Zvolil jsem features, prestoze ma Scala (udajne dobrou) actor knihovnu Akka, ale s tou skoro neumim.
def getData = Future {Thread.sleep(50); 4}
def processData(a: Int) = Future {Thread.sleep(50); a * 2}
val totalResultFuture = for {
data <- getData
result <- processData(data)
} yield result
val totalResult = Await.result(totalResultFuture, 2 seconds)
setValue(totalResult)
-
Ta stupnice mezi jedničkou a dvojkou má dvě desetinná místa, plus další místo se dá odhadnout. Za dvojkou se už odhaduje to druhé desetinné místo, takže na přesnost 0.1 % se to při troše pečlivosti dalo dotáhnout.
Zajímavé na tom logáru je, že se dá násobit a dělit současně, což je neskutečná výhoda.
Logára co tu mám (plastová) by byla tak třikrát nepřesnější, možná kromě toho kovového dederonského. 8)
Jo, spočítat plochu kruhu obnáší jeden pohyb posuvníku, a tím je číslo umocněné a navrch ještě vynásobené Pí. Kdybych měl vybrat deset největších vynálezů všech dob, tak by logaritmické pravítko určitě nechybělo, a daleko za kolem a rozděláním ohně by se neumístilo.
Nevím, jestli jste viděl speciální logáro pro zemědělce (po novu nejspíše pro farmáře). Nastavíte datum připuštění a o kus dál si přečtete datum ohřebení, otelení, obahnění, oprasení atd. - pochopitelně s případným přechodem do dalšího roku. Má i jiné stupnice, třeba pro agrotechnické lhůty. V tomto oboru ovšem na nějaké desetině nezáleží :-). Jinak jsem je viděl u známého, který byl jako potomek kulaka zrůdným režimem pronásledován v 50. letech tak strašlivě, že vysokou zemědělskou absolvoval dálkově (považte!) a později (asi za trest) dělal předsedu úspěšného JZD; po jeho rozbití pak soukromničil na jednom z jeho zbytků. Své práci rozuměl skvěle a na logáro nedal dopustit.
-
[/quote]
Příroda se spojitě jenom tváří, ve skutečnosti si s celými čísly úplně vystačí. To jenom omezené lidské myšlení nedokáže obsáhnout přesný počet atomů ve sklenici vody, proto si musí vypomoci umělými makrojednotkami jako je litr, a "reálnými" čísly, popisujícími velmi přibližně celočíselnou realitu. Jako to logaritmické pravítko - nepřesně ale rychle.
Takže je to přesně naopak, přesné počítání s celými čísly je pro pánaboha, lidé si musí vystačit s nepřesnými reálnými. Mimochodem, černé díry jsou místa ve Vesmíru, kde Bůh dělil nulou ;D
[/quote]
byl by k tom nejaky odkaz na clanek kde se to vic vysvetluje ? ja mel za to ze prave lidstvo hlavne fyzikove si musi vystacit s modely, aproximacemi tedy "prirozenymi cisly" .. zatimco priroda pracuje v realnem oboru (radove treba 10 ^30 cislic za desetinnou carkou nebo i vic ) a my proste nejsme schopni tuto opravdovou "realitu"namerit a pak s takovou presnosti pracovat, nekonecno je asi spis lidsky konstrukt nez v prirode se realne vyskytujici entita vsechno zase asi za ucelem zjednoduseni,aproximace a moznosti zaveru ... je to stochasticke (vyjimka kvantovka tam se to ma za prokazane byt einstein viz EPR paradox nesouhlasil, viz skryte elementy reality )
-
Ty taky určitě něco znáš líp než většina populace. Řekněme třeba se zabýváš filozováním o životě a smyslu věcí což je něco co drtivá většina lidí nedělá. Jsou v tomto ohledu ignoranti, choděj do práce, domů. Čuměj na ty debilní seriály pořád dokola bez snahy se někam posunout, to čemu rozumíš ty oni nerozuměj a nezajímá je to a nechápou proč to zajímá tebe.
Já jako programátor to vidím obdobně. Vysvětlovat neprogramátorovi jaký to je je jako vysvětlovat to psovi. Bude na tebe čumět a může ti chvilku i připadat že ti rozumí ale pak ti dojde že je to jen blbej pes a že tomu nemůže rozumět, je to marný.
Ptát se jaké je to být programátorem je ptát se jaké je to být bohem. Jedinej způsob jak pochopit jaký je být programátorem je stát se jím. Pokud máš rád filozofování o smyslu a fungování věcí, tak programování tě nakopne na úplně novej level. Ale je to nebezpečný, může se ti stát že tě to tak chytne že tě už nebude zajímat nic jinýho. :-)
-
Re. Ale je to nebezpečný, může se ti stát že tě to tak chytne že tě už nebude zajímat nic jinýho.:
Což je mimochodem ukázka uvažování o krajní mezi.
Logika, abstrakce, dekompozice, vnímavosti k možným (i málo pravděpodobným) stavům,... to jsou věci, které si nosíme (občas i k pobavení publika) do života mimo svou práci. Někdy nám to přemýšlení zkříží někdo s praktickým selským rozumem a v daném prostředí vymyslí či zrealizuje něco mnohem efektivněji.
Nezřídka však platí, podobně jako v jiných případech, "ševcova žena a kovářova kobyla...", takže to může někdy vypadat, že logiku odkládáme stranou.
Možná je to proto, že v některých oblastech je použití logiky témeř nepoužitelné (komunikace s partnerkami a úředníky) a bez této půdy pod nohami můžeme být trochu ztracení.
-
Psycholožka není partnerka.
-
Ty taky určitě něco znáš líp než většina populace. Řekněme třeba se zabýváš filozováním o životě a smyslu věcí což je něco co drtivá většina lidí nedělá. Jsou v tomto ohledu ignoranti, choděj do práce, domů. Čuměj na ty debilní seriály pořád dokola bez snahy se někam posunout, to čemu rozumíš ty oni nerozuměj a nezajímá je to a nechápou proč to zajímá tebe.
Já jako programátor to vidím obdobně. Vysvětlovat neprogramátorovi jaký to je je jako vysvětlovat to psovi. Bude na tebe čumět a může ti chvilku i připadat že ti rozumí ale pak ti dojde že je to jen blbej pes a že tomu nemůže rozumět, je to marný.
Ptát se jaké je to být programátorem je ptát se jaké je to být bohem. Jedinej způsob jak pochopit jaký je být programátorem je stát se jím. Pokud máš rád filozofování o smyslu a fungování věcí, tak programování tě nakopne na úplně novej level. Ale je to nebezpečný, může se ti stát že tě to tak chytne že tě už nebude zajímat nic jinýho. :-)
urcite mas pravdu a docela jsi mne vystihl, zkousim to, ale rad se treba "zaparkovavam" do neciho videni sveta, citeni, takovy pokus o empatii a prociteni onoho pro mne i Vas tezko popsatelneho stavu rozpolozeni, videni sveta, zrejme chci po Vas nemozne, ale aspon jsme to zkusili
ale dekuju za snahu o prvni ci druhe priblizeni pomoci ruznych podobenstvi ze zivota (jako v Bibli )
treba vcera jsem prohanel 200 MB soubor (2,1 mil radku) skrz regularni vyraz abych se zbavil html tagu a dostal cistej text pomoci regularniho vyrazu ktery jsem samozrejme musel "si vypujcit"pres strycka googla, ale kdybych nevedel ze existuji reg. expr. resp. moznost zbaveni se html tagu tak bych vlastne ani nic nehledal ... jak to prosivalo ten soubor skrz reg. expr. sito tak mi to prislo az demonicke ... takova "trivialnost"pro Vas, pro mne "zazrak"kdybych to mel delat rucne
-
treba vcera jsem prohanel 200 MB soubor (2,1 mil radku) skrz regularni vyraz abych se zbavil html tagu a dostal cistej text pomoci regularniho vyrazu
Tak tohle mi přijde jako brutální overkill. Co to HTML jednoduše zobrazit v prohlížeči a text zkopírovat?
-
Nebo elinks -dump či starší lynx -dump.
-
diky zkusim, ale jsem spis takovy filosof-teoretik ktery se proste rad jen "neprakticky"zamysli treba nad tim, jak formuje dlouholete programovani mysleni cloveka, ktere se asi uplatnuje treba i v beznem zivote (stejne jako treba pravnicke mysleni atd..), zkratka asi by me zajimal
https://en.wikipedia.org/wiki/Mental_model tech lepsich programatoru
nejake clanky jsem uz zkusil hledat v Googlu, treba
Mental models, consistency and programming aptitude.
zdaleka se nepocitam mezi lepsi programatory. programator je nekdo, kdo ma svoje piskoviste pripravene domaci ci nadnarodni korporaci a jako pstros ma hlavy zarazenou radne hluboko v pisku.
teto chyby piskovistove omezenosti se mi podarilo zprostit pred cca 5ti lety.
jinak pokud se bavime o obecnem zpusobu premysleni, tak u me prevazuje reverzni inzenyrstvi aplikovane na zivotni situace.
cili sledovat. analyzovat. formulovat nekolik hypotez a syntetizovat nejaky priblizny model. vytvorit situaci, ve ktere je sance provest mereni alespon jedne hypotezy. nasledne porovnat vysledky s ocekavanim. pokud me to bavi opakovat proces s korigovanymi hypotezami dal nebo prohlasit situaci za vyresenou ci nezajimavou.
pak je tu jeste druha cast. uplneho vypnuti teto casti osobnosti, kde pak zustavaji rigidni analyticke kognitivni mechanismy, ale dohromady k nim se projevuje nezajem s nimi dale pracovat jinak nez nahodne oportunisticky. v takove situaci pak obvykle slysim od absolventky specialni pedagogiky okridlenou vetu: ty se chovas jak petileta holka. nebo od nekoho mene presneho jak petilete decko.
-
kuprikladu ted z nedavne reverzni analyzy jedne osoby a zpusobu jeji prace:
ja resim zadany ukol, osoba sleduje a analyzuje.
ja flagrantne porusim zadani a prestanu se venovat ukolu a zhodnotim praci sledujici osoby.
celkova strnulost jen tekajici oci usekovite.
cili formuluji hypotezu 1: odmeruje mi cas tak aby to nebylo prilis okate
hypoteza 2: modeluje asociace, ktere jsou meziproduktem analyzy jak zpracovavam ukol
hypoteza 3: nudi se a jde o okulokinetickou stimulaci, autoregulacni techniku proti zanedbavani z absence pozornosti
mereni momentalne nedokonceno.
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
k problemu sklenice uz ovsem existuji dostatecne kvalitni edukacni materialy na kterych se odnaucite vnimat takhle vyhranene zadani problemu:
2 girls 1 cup
1 girl 1 pitcher
1 man 1 jar
-
zajimave muselo byt urcite treba programovani v NASA pro projekt Apollo, pozdeji pro raketoplany, nebo i obycejnejsi programy pro Airbusy nebo rizeni letoveho provozu, asi by se mi trochu roztrasly kolena kdybych vedel ze programuju neco na necem fyzicky visi zivoty lidi, ono ale asi i treba internetove bankovnictvi, burzovni sw pro algorithmic trading atd. musi byt zajimave
celkem bezne. vzdycky hrozi, ze nekdo minimalne skoci z okna po tom co se neco rozbije. na to se da zvyknout.
bezpecnost financnich transakci svetoveho obchodu nebo bezpecnost v letecke preprave... stejne ty mrtvy nikdy neuvidis, jsou to jen cisla. staci akorat vedet, ze bys na dovolenou fakt nemel chtit letenku. v dobe, kdy ty systemy pravdepodobne nebudou zalohovany dostatecnym mnozstvim lidskyho faktoru. cili fakt nechces litat ve spicce letecke+dovolenkove sezony.
co podle Vas ma ted nejvetsi perspektivu (dejme tomu na 40 let dopredu, dal asi videt neni ? AI, machine learning, support decesion sw, data mining, nebo se v tomto stoleti dockame nejakeho (dnes to jeste je jen na papire nebo ani to ne) fakt prulomu ktery se dnes zda spis sci-fi ale bude realitou, treba opravdu myslici stroje samoucici, selfrepairing, ktere zastoupej primo lidi pri rozhodovani (vzdyt treba letadla by uz mohly brzy samy vzletat a pristavat) apod. umoznujici treba bruteforce metodou otestovat vsechno v domenach, ktere jsou nam zatim nepristupne, kvantove pocitace, vzdyt treba i zmena pocasi je deterministicka jen nemame tu silu to vcas vypocitat (deterministicky chaos), asi to spis budou veci az pro 22. stoleti ?
jsem laik treba mluvim hlouposti, ale zajimalo by mne jak to bude v roce 2050, 2100, mam pocit ze ted se jen dotahuji stare koncepty do detailu ale nic noveho na obzoru ?
blablabla. co? momentalne tohle ceka na dalsi krucek v podobe prace s topologiemi masivne paralelnich mezivysledku.
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
k problemu sklenice uz ovsem existuji dostatecne kvalitni edukacni materialy na kterych se odnaucite vnimat takhle vyhranene zadani problemu:
2 girls 1 cup
1 girl 1 pitcher
1 man 1 jar
jinak 2 girls 1 cup te nauci, ze filosoficke i kognitivni zkoumani otazky "je slenice zpuli prazdna, ci zpuli plna" je zatizeno chybou vyzkumnika. protoze definice plnosti je situacne podminena. plnost v pripade 2 girls 1 cup je spojity stav vcetne kopecku nad sklenici a je podminena tedy gravitaci, soudrznosti+stekavosti, cili povrchovym napetim a viskozitou cili otazka neni diskretni jak se vyzkum snazi ukazat, ale je provazna jak na parametry uvnitr, tak vne zkoumaneho systemu.
1 girl 1 pitcher te pak nauci, ze otazka plnosti je temporalne zavisla. da se za plnost oznacit oznacit vyliti+doplneni, kdy nebylo dosazeno kraje, ale celkove mnozstvi by znamenalo preplneni?
1 man 1 jar te pak nauci myslet mimo ramec obvyklych modelu. kdy pochopis podstatu paradoxu sklenice je soucasne plna i prazdna, sklenice soucasne je i neni.
-
Nejspíš Air Inter 148.
Tohle je jiný případ, tady byl problém v nevhodném zobrazení hodnot na displeji. To co myslím já ale proběho podobně, s tím že počítač na rychlý pohyb řízení reagoval jako na dvounásobnou výchylku. Asi jako by auto při rychlém cuknutí volantem natočilo kola do plného rejdu, i když řidič cuknul jenom o kousek. A při nulové viditelnosti pilot nestihl zjistit že se to letadlo sklonilo víc než chtěl.
takhle to dopada, kdyz jde programator z desktopu windows programovat rizeni letadla. aneb akcelrovana mys v letecke praxi.
jsem zvedavy, jestli by letadle zustal knipl, kdyby tam sel delat nekdo z gnomu.
-
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový (https://cs.wikipedia.org/wiki/Analogov%C3%BD_po%C4%8D%C3%ADta%C4%8D).
Analogové počítače jsou super. Jednoduché, funkční a nemusí se řešit nějaký kmitočet procesoru, protože vše běží v reálném čase.
dalo by se nejak prirovnat analogove/digitalni *** spojite/diskretni vstupy *** realna/priblizna cisla ?
nekde jsem cetl ze realna cisla (pocitani v nich) je pro panaboha, pro nas bezne smrtelniky vzdy pracujeme pouze s urcitou aproximaci (viz napr. pi atd..), coz je u neketyrch systemu problem, potrebovali bysme na vstup davat realna cisla (napr. deterministicky chaos) priroda v nasich meritkach (ne kvantovka) je asi spis spojita nez diskretni tak by se vic hodily na vstup ty spojite signaly a analogove pocitace ?
tohle jde uplne nejlepe primo na osobe diskretni = prepis reci do textoveho retezce, spojite funkce ovladani hlasivek a mimiky k vysloveni toho stejneho textoveho retezce.
-
na tom je ostatne videt i proc soucasne AI postupy selhavaji. zatimco to ovladani reci je prirozene masivne paralelni proces s topologickou zavislosti diskretni vysledek je neco co vznikne az analyzou toho predchoziho.
-
určitě je lepší než napsat:
red_cars = map(lambda x: x.color = 'red', filter(lambda x: x.id == 'ID2376', cars))
je lepší napsat
def set_color(color):
return lambda x: x.color = color
def where_id(id):
return lambda x: x.id == id
car.id = 'ID2376'
red_cars = map(set_color('red'), filter(where_id(car), cars)
protože pak můžete v budoucnosti vylepšit vyhledávání pomocí regulárního výrazu, nebo strukturovat data různých entit a typů podle jednotné šablony, obsahující id, barvu a podobně.
Imho je lepší:
def filter_cars(cars, color, id):
for car in cars:
if car.id == id:
car.color = color
yield car
red_cars = filter_cars(cars, color="red", id="ID2376") # případně to obalit list()em, aby z toho bylo pole a ne generátor
Mimochodem red_cars = map(lambda x: x.color = 'red', filter(lambda x: x.id == 'ID2376', cars)) fungovat nebude, protože výsledkem první definované lambdy je SyntaxError: can't assign to lambda. Lambdy totiž můžou obsahovat jen výrazy, nikoliv příkazy (což je přiřazení). I kdyby to náhodou šlo, tak to stejně nemusí fungovat jak bylo očekáváno, protože výsledkem by byla hodnota přiřazení a nikde není psáno, že musí fungovat jako Cčkovské jazyky. Výsledkem tak může být třeba None, True, či 'red', nikoliv původní objekt x (a ano, viděl jsem jazyky, kde to tak je).
Toto je veliký omyl. Naučit se pár příkazů je záležitost jednoho dne. Ale každý jazyk ma trošku jinou filozofii a komunitu lidí. A proto i tak příbuzné jazyky jako třeba Python, Ruby nebo Javascript jsou z hlubšího pohledu hodně odlišné, existují v nich naprosto odlišné idiomy a přetransformovat se z jednoho na druhý neznamená naučit se pár příkazů, ale porozumět jak v nich programy tvořit, poznat ekosystém, používané knihovny atd. A to je záležitost několika měsíců, minimálně. A poměrně hodně samostudia zdrojových kódů ikonických implementací. A to vůbec nemluvím o filozoficky úplně rozdílných jazycích.
Ano, je to často opakovaná blbost. Jaksi tam chybí, že se takhle člověk naučí jen ekvivalentní výrazy těm co už znal a ne využívat všech featur, které jazyk nabízí. Na pomyslném žebříku abstrakce to tedy funguje jen jako horizontální přestup.
Člověk co vylezl na vrchol žebříku javy může přeskočit na pythonní žebřík docela rychle, ale rozhodně nebude na vrcholu pomyslného žebříku možné pythonní abstrakce. Naopak bude někde úplně dole. Lidi z javy pak v pythonu javí a javí a z toho jejich kódu bych blil. Myslet si, že takhle přejdou třeba do lispu a budou v něm efektivní a jejich kód nebude k zblití je úplně mimo.
Zažil jsem třeba docela dost lidí, co si takhle mysleli, že umí python. Pak jim málem shořel mozek, když viděli https://www.youtube.com/watch?v=sPiWg5jSoZI
-
tomu shoreni hlavy se nelze divit.
java byla navrzena tak, aby v ni neslo prasit milionpadesativrstevna makra jako jsou k dispozici v jazyku C a po prevzeti projektu nebo po navratu po letech k casti kodu je takova cast neopravitelna - write only - protoze se po expanzi neda lacine dohledat z kterych souboru se co pouzilo a co se nahradilo za jakou cast. jde to zcela proti navrhove filosofii javy a cilove skupine, ktera klade pozadavky na snadnou vyhoditelnost programatora managmentem a rychly outsourcing do bangladese.
cilova skupina uziti javy neni programator a jeho hracickovani, ale pragmaticka korporace ve ktere se programatori trhaji obdobnym tempem jako toaletni papir. pak se nelze divit. pri takto kladenych navrhovych pozadavcich na jazyk ze kterych plynou pozadavky na vyssi naklady na vyhledani odpovidajiciho apaticko-masochistickeho javoveho zjeva je zcela jasne, ze vzhledem k mire apatie projevene k vlastni osobe, kde jedinou a nejvyssi modlou je monetarni kompenzace za ni nebude ani zajem o moderne prekombinovane objektove makra.
-
Dlouhé řádky nejsou čitelné.
Pointa přece není v dlouhém řádnku, dá se to klidně zalomit (a já to vždycky dělám) ale v tom, že se čte zleva doprava. Což, uznávám, může Arabům z Židům přijít nepřirozené.
navíc oproti mému řešení v Pythonu je ve vašem zápisu mnohem více redundandních znaků, například |>, &,
Nevím, co to je "redundantní znak". "Reduntantní" znamená "nadbyčný". V tom příkladu ale mají všechny znaky význam, není tam žádný znak, který by bylo možné bez ztráty významu vypustit. Nevím teda, proč by některé měly být redundantní.
u lambda výrazů musíte v hlavě postupně simulovat co dělají, nemůžete s nimi pracovat jako se symbolem, tudíž ztrácíte nadhled nad kontextem.
Samozřejmě pokud někdo v rámci jednoho řádku ztrácí schopnost vnímat význam, je lepší, když si všechno pojmenuje. S tím naprosto souhlasím. Škoda, že přirozený jazyk tu možnost nemá a člověk musí analyzovat celou větu i když je třeba přes několik řádků :)
Je ale možné, že někdo je čte jako slova, naskočí mu simulace sama, jako když si přečte slovo jablko, tak uvidí vnitřním zrakem jablko, to ale můj případ není. Zajímalo by mě, zda to někdo takto umí. Je to váš případ?
Nevím, o jaké "simulaci" je řeč. Když vidím v kódu "|> Enum.map(fn x -> x +1 end)", tak vím, že tahle pasáž kódu postupně k prvkům Enumerable přičítá jedničku. Stejně tak když někde v textu vidím větu "Miloš Zeman dostal včera hustou virózu", tak chápu, že Miloš Zeman dostal hustou virózu, protože rozumím sémantice a zvládnu si tu větu celou zapamatovat, abych mohl pochopit význam jejího sdělení. Jestli je to "jablko", to netuším, té analogii nerozumím.
No a pak přijde zákazník s tím, že potřebuje vyhledávat ne podle id, ale podle regulárního výrazu nad id, u mě to znamená, že upravím jednu funkci, a u vás to znamená, že musíte procházet všechny lambdy v aplikaci, protože někde jste použil jako proměnnou x, jinde třeba id atp., na významově totéž.
Ne. Pokud se jedna věc dělá na více místech, tak se samozřejmě má použít pojmenovaná funkce, protože je znovupoužitelná. Pokud se ten kód používá jenom na jednom místě, použije se funkce nepojmenovaná, protože není důvod ji pojmenovávat. Jasný jak facka, co je na tom k dumání?!
-
Nějak jsem nepochopil ten tvůj JS kód, zvláště pak proč předávat parametry data a callback do funkce some_other_async, když jsou pro ni dostupné přes závoru.
"Závora" je překlep a mělo být "uzávěr" (closure)? Pokud ano, tak parametry jsou tam explicitně proto, že fci some_other_async chci třeba používat i někde jinde, ne? Nicméně pro obsah sdělení je to úplně irelevantní, klidně tam ty parametry být nemusí, pointa se tím nijak nemění.
Pro podporu svých argumentů není potřeba protivníka záměrně potápět... ;)
Nejsem si vědom potápění. Prostě říkám, že někteří lidé znají některé věci z jazyků, kde jsou otřesně implementované a pak si myslí, že je ta věc otřesná an sich. V jiných jazycích ale může být implementovaná líp.
Taky nesouhlasím s tvým vyjádřením ohledně ES6 (navíc hodně toho jde i v ES5), kromě callbacků můžu použít promises, generátory a async/await (ES7, ale s babelem je to jedno).
Promises detailně neznám, ale pokud se nepletu, nijak neřeší to, co jsem říkal. Návratovou hodnotu asynchronního volání nejde v JS z funkce vrátit. Jestliže to obejdu tím, že vrátím nějaký objekt, který zapouzdřuje nějaký callback, který se spustí až někdy jindy, tak to není vrácení návratové hodnoty asynchronního volání, i když ta syntaxe to nakrásně může připomínat.
Pokud se pletu a už to v JS nějak jde, budu vděčný za poučení, protože mě to neskutečně rozčiluje a milerád bych se tomu vyhnul.
A celý humbuk okolo microservices z velké čísti pochází z node.js.
To je úplně absurdní tvrzení. Asi tak stejný jako že Docker vymyslel kontejneriazci, která se používala patnáct let před ním. "Microservices" není nic jinýho než buzzword - nové pojmenování pro koncept, který má Erlang třicet let.
-
Promises detailně neznám, ale pokud se nepletu, nijak neřeší to, co jsem říkal. Návratovou hodnotu asynchronního volání nejde v JS z funkce vrátit.
Jo, tak jsem si to pamatoval dobře. Promises nejsou nic víc než řetězení funkcí/callbacků, viditelně inspirované monádami. Čili je to pořád jenom takový cukr, na podstatě to nic nemění - JS je jednovláknová záležitost, kde blokování fce (tak jako právě v Erlangu/Elixiru) nepřipadá v úvahu. Čili se pořád musí udělat stejný špinavý trik - vlákno de facto opouští jazyk jako takový, aby mohlo udělat async akci, a vrací se zpátky do callbacku. A z callbacku jaksi návratovou hodnotu z původní fce vrátit nejde :)
Pokud to pořád není jasné, upovídanější popis: http://joearms.github.io/2013/04/02/Red-and-Green-Callbacks.html (píše se tady o starém způsobu s callbacky, ale promises na tom nic nemění)
-
... Čili je to pořád jenom takový cukr, na podstatě to nic nemění - JS je jednovláknová záležitost, kde blokování fce (tak jako právě v Erlangu/Elixiru) nepřipadá v úvahu. ...
Nikdy jsem to nepouzil, ale web workers (https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) vypadaji, ze bezi v jinem vlaknu.
Nevim, jestli to uplne souvisi, ale treba LiveScript ma zajimavou feature - backcally (http://livescript.net/#functions-backcalls), ktere umoznuji nezanorovani callbacku.
do
data <-! $.get 'ajaxtest'
$ '.result' .html data
processed <-! $.get 'ajaxprocess', data
$ '.result' .append processed
JS:
$.get('ajaxtest', function(data){
$('.result').html(data);
$.get('ajaxprocess', data, function(processed){
$('.result').append(processed);
});
});
Po tom, co se hodne zajimavych veci z CoffeeScriptu dostalo do JS, verim, ze nemusi byt uplne nerealne, ze se dockame nejake obdoby backcallu i v JS :).
-
Nikdy jsem to nepouzil, ale web workers (https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) vypadaji, ze bezi v jinem vlaknu.
To je taky známá berlička - mám jednovláknový jazyk, tak pustím paralelně druhý interpret. Používá se to v Pythonu i v Rku. Na některé věci to stačí (parmap), ale v principu je to zoufalost.
Nevim, jestli to uplne souvisi, ale treba LiveScript ma zajimavou feature - backcally (http://livescript.net/#functions-backcalls), ktere umoznuji nezanorovani callbacku.
Ne, to s tím, co jsem psal, nesouvisí, tohle je (pokud to správně chápu) opět jenom syntaktický cukr. Hodnotu z callbacku do původní fce pořád nedostaneš. Pokud to cílový jazyk neumí, tak s tím transpiler nic neudělá...
-
Dlouhé řádky nejsou čitelné.
Pointa přece není v dlouhém řádnku, dá se to klidně zalomit (a já to vždycky dělám) ale v tom, že se čte zleva doprava. Což, uznávám, může Arabům z Židům přijít nepřirozené.
Spíše měl asi na mysly dlouhé výrazy. Zalomení dlouhého výrazu na 2-3 řádky se, alespoň u mě, čitelnosti moc nepomůže, možná spíš naopak. Pro někoho (včetně mě) je lepší, když se to rozloží na více menších kroků.
- java byla navrzena tak, aby v ni neslo prasit milionpadesativrstevna makra jako jsou k dispozici v jazyku C ...
- cilova skupina uziti javy neni programator a jeho hracickovani...
I v jednoduchéma jazyku se snad daj dělat složité projekty a algoritmy. Je pravda, že Java není vhodná pro nejaké onanistické hračičky co masturbují nad tím, jak složitě překombinovaný kód dokážou vymyslet. Jsou lidé, kteří z jazyka se naučí nezbytné minimum pro svůj cíl, ale dokážou udělat promyšlenou aplikaci, kterou je radost používat.
-
Dlouhé řádky nejsou čitelné.
Pointa přece není v dlouhém řádnku, dá se to klidně zalomit (a já to vždycky dělám) ale v tom, že se čte zleva doprava. Což, uznávám, může Arabům z Židům přijít nepřirozené.
Spíše měl asi na mysly dlouhé výrazy. Zalomení dlouhého výrazu na 2-3 řádky se, alespoň u mě, čitelnosti moc nepomůže, možná spíš naopak. Pro někoho (včetně mě) je lepší, když se to rozloží na více menších kroků.
Dlouhé řádky také nepoužívám - mám softlimit někde kolem 65 znaků. Zpravidla se delší výraz dá rozdělit na několik pojmenovaných podvýrazů, každý na samostatném řádku - což kódu přidá na čitelnosti, protože pojmenovaný výraz mi zároveň slouží místo komentáře.
Krátké řádky mi také umožnily zbavit se prázdných řádků uvnitř metod. Zkracování řádek tedy nijak neprodloužilo mé programy. Spíš zkrátilo.
-
Nějak jsem nepochopil ten tvůj JS kód, zvláště pak proč předávat parametry data a callback do funkce some_other_async, když jsou pro ni dostupné přes závoru.
"Závora" je překlep a mělo být "uzávěr" (closure)? Pokud ano, tak parametry jsou tam explicitně proto, že fci some_other_async chci třeba používat i někde jinde, ne? Nicméně pro obsah sdělení je to úplně irelevantní, klidně tam ty parametry být nemusí, pointa se tím nijak nemění.
Pro podporu svých argumentů není potřeba protivníka záměrně potápět... ;)
Nejsem si vědom potápění. Prostě říkám, že někteří lidé znají některé věci z jazyků, kde jsou otřesně implementované a pak si myslí, že je ta věc otřesná an sich. V jiných jazycích ale může být implementovaná líp.
Taky nesouhlasím s tvým vyjádřením ohledně ES6 (navíc hodně toho jde i v ES5), kromě callbacků můžu použít promises, generátory a async/await (ES7, ale s babelem je to jedno).
Promises detailně neznám, ale pokud se nepletu, nijak neřeší to, co jsem říkal. Návratovou hodnotu asynchronního volání nejde v JS z funkce vrátit. Jestliže to obejdu tím, že vrátím nějaký objekt, který zapouzdřuje nějaký callback, který se spustí až někdy jindy, tak to není vrácení návratové hodnoty asynchronního volání, i když ta syntaxe to nakrásně může připomínat.
Pokud se pletu a už to v JS nějak jde, budu vděčný za poučení, protože mě to neskutečně rozčiluje a milerád bych se tomu vyhnul.
A celý humbuk okolo microservices z velké čísti pochází z node.js.
To je úplně absurdní tvrzení. Asi tak stejný jako že Docker vymyslel kontejneriazci, která se používala patnáct let před ním. "Microservices" není nic jinýho než buzzword - nové pojmenování pro koncept, který má Erlang třicet let.
Async a await dosud enginy nepodporujou, až budou, budeš moct tudle kokotinu použít pro pozastavení aktuálního tasku, spuštění ostatních tasků z event fronty zatímco engine bude čekat na výsledek async volání. Node.js něco podobnýho už má díky C++ pluginu.
-
Nikdy jsem to nepouzil, ale web workers (https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) vypadaji, ze bezi v jinem vlaknu.
Po tom, co se hodne zajimavych veci z CoffeeScriptu dostalo do JS, verim, ze nemusi byt uplne nerealne, ze se dockame nejake obdoby backcallu i v JS :).
Workers je možná implementováno jako samostatné vlákno, ale z hlediska JS funguje jako samostatný proces, jeden, nikoliv jediný, rozdíl je v tom že se nekoná sdílení dat mezi vlákny.
V JS je zcela nereálné dočkat se čehokoliv podobného Erlangu a spol.
Dlouhé řádky také nepoužívám - mám softlimit někde kolem 65 znaků.
To už víme, máš malý monitor :) Dneska je normální vidět na šířku 120 znaků najednou.
-
Async a await dosud enginy nepodporujou, až budou, budeš moct tudle kokotinu použít pro pozastavení aktuálního tasku, spuštění ostatních tasků z event fronty zatímco engine bude čekat na výsledek async volání. Node.js něco podobnýho už má díky C++ pluginu.
Node.js nic takového nemá, nejde pozastavit vykonávání funkce. Funkce musí doběhnout, aby se mohl zavolat callback/lambda.
-
Dlouhé řádky také nepoužívám - mám softlimit někde kolem 65 znaků.
To už víme, máš malý monitor :) Dneska je normální vidět na šířku 120 znaků najednou.
Tak uveď důvod, k čemu jsou dobré řádky programu delší než 80 znaků. Zhoršuje to čitelnost - oko se na tak dlouhém řádku prostě neudrží.
Už jsi někdy přemýšlel o tom, proč se noviny sází do sloupečků?
-
Dlouhé řádky také nepoužívám - mám softlimit někde kolem 65 znaků.
To už víme, máš malý monitor :) Dneska je normální vidět na šířku 120 znaků najednou.
Tak uveď důvod, k čemu jsou dobré řádky programu delší než 80 znaků. Zhoršuje to čitelnost - oko se na tak dlouhém řádku prostě neudrží.
Už jsi někdy přemýšlel o tom, proč se noviny sází do sloupečků?
Mne zase na 80znakovych radcich prijde klicova moznost zobrazit na fullhd displeji tri takove soubory vedle sebe.
-
Mne zase na 80znakovych radcich prijde klicova moznost zobrazit na fullhd displeji tri takove soubory vedle sebe.
Ano, to je další možnost využití, pokud někdo nemá plochu zleva i zprava oblepenou nástrojovými lištami. Tři kompletní třídy na jedné ploše - to se prostě vyplatí.
-
Mě zase příjde, že dodržování 80 znakových řádků zhoršuje orientaci v kódu, prostě se mi nelíbí, když se tam kvůli tomu zalamuje funkce, nějak se mi v tom potom hůř orientuje.
Někteří píšou kvůli tomu funkce takhle:
pom = funkce(jedna,
dva,
tři,
čtyři,
pět,
šest);
pom12345 = funkce(jedna,
dva,
tři,
čtyři,
pět,
šest);
Na mě to působí docela neesteticky, když je program takhle roztahaný na hodně řádků. Potom někteří dělají:
if( podminka )
{
jedna;
dva;
};
misto
if( podminka ) {
jedna;
dva;
}
Zároveň mi příjde o ničem nadužívat zkracování jmen proměnných. Každé ide dneska má našeptávání, podle mě rpoměnné by se mohly psát klidně bez jakýchkoliv zkratek. Ztejně tam pak musíte valit komentáře, lepší je samopopisná proměnná. Nejspíš nějaký pozůstatek z doby dávno minulé u starých pardálů.
-
Mě zase příjde, že dodržování 80 znakových řádků zhoršuje orientaci v kódu, prostě se mi nelíbí, když se tam kvůli tomu zalamuje funkce, nějak se mi v tom potom hůř orientuje.
Dlouhou funkci s mnoha parametry zalamuji jinak:
vysledek = funkce(
jedna,
dva,
tři,
čtyři,
pět,
šest
);
Zároveň se vyhýbám víc než 3 parametrům metody. Obvykle stačí jeden nebo dva. Jinak se čtenář ztrácí v tom, "co ten čtvrtý parametr znamená?".
"if" také zarovnávám jinak:
if (podminka) {
jedna;
dva;
}
(za klíčovým slovem mezera, závorka obepíná podmínku, větev else zpravidla není žádná)
Zároveň mi příjde o ničem nadužívat zkracování jmen proměnných. Každé ide dneska má našeptávání, podle mě rpoměnné by se mohly psát klidně bez jakýchkoliv zkratek. Ztejně tam pak musíte valit komentáře, lepší je samopopisná proměnná. Nejspíš nějaký pozůstatek z doby dávno minulé u starých pardálů.
Zkratky v názvech proměnných (kromě uznávaných) jsou zlo. Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
-
Když si vytáhnu z manuálu funkci s pěti parametry, tak místo zalamování se dá napsat třeba takto:
<?php
$filename = "source.txt";
$usePath = false;
$context = stream_context_create();
$offset = -1;
$maxlen = 100000;
$content = file_get_contents($filename, $usePath, $context, $offset, $maxlen);
Přestože má ta funkce 5 parametrů, poslední řádek s jejím voláním má celkem 78 znaků. Navíc jsou všechny parametry pojmenovány tak, že je evidentní jejich účel a plní roli komentářů.
-
Když si vytáhnu z manuálu funkci s pěti parametry, tak místo zalamování se dá napsat třeba takto:
<?php
$filename = "source.txt";
$usePath = false;
$context = stream_context_create();
$offset = -1;
$maxlen = 100000;
$content = file_get_contents($filename, $usePath, $context, $offset, $maxlen);
Přestože má ta funkce 5 parametrů, poslední řádek s jejím voláním má celkem 78 znaků. Navíc jsou všechny parametry pojmenovány tak, že je evidentní jejich účel a plní roli komentářů.
V tomhle mi teda přijde lepší využít defaultní parametry:
content = file_get_contents(
filename="source.txt",
usePath=False,
context=stream_context_create(),
offset=-1,
maxle=100000,
)
-
Pojmenovane parametry jsou fajn, napr. Scala je podporuje "out of the box", neni ani treba je nejak specialne resit.
def someFunction(firstParam: Int, secondParam: String, thirdParam: Boolean) {}
someFunction(
1,
"",
true
)
someFunction(
firstParam = 1,
secondParam = "",
thirdParam = true
)
V JS jsem to videl vetsinou resene pres options objekt, coz ve spojeni s kratkou syntaxi vytvoreni objektu je IMO celkem hezke:
function someFunction(options) {}
someFunction({
firstParam: 1,
secondParam: '',
thirdParam: true
});
Jsem nasel i nejaky udelator pro JS, ktery prevede funkci s nekolika pojmenovanymi parametry na funkci akceptujici options objekt.
// using http://stackoverflow.com/a/11796776/1017211
var someFunction2 = parameterfy(function (firstParam, secondParam, thirdParam) {
console.log(firstParam + ' ' + secondParam + ' ' + thirdParam);
});
someFunction2(
1,
'x',
true);
someFunction2({
firstParam: 1,
secondParam: 'x',
thirdParam: true
});
A po pravde nevim, co vam vadi na vyrazu pres nekolik radku. FP varianta na nekolik radku, kde kazdy dela jednu jednouduchou operaci se mi libi podstatne vice, nez mit nekolik cyklu na jeste vice radcich s ruznymi, nejlepe propletenymi, side-effecty jen proto, ze nekdo nezna zaklady FP v jeho jazyce.
Dokonce i ten trivialni priklad se mi libi vice FP stylem:
val redCars = cars
.filter(_.id == "ID2376")
.map(c => {c.color = "red"; c})
var redCarsNonFp = Seq[Car]()
for (car <- cars) {
if (car.id == "ID2376") {
car.color = "red"
redCarsNonFp :+= car
}
}
A co vic, FP zapis se da casto krasne napsat na jeden radek, druha varianta je vetsinou necitelna.
val redCars = cars.filter(_.id == "ID2376").map(c => {c.color = "red"; c})
var redCarsNonFpShort = Seq[Car](); for (car <- cars) { if (car.id == "ID2376") {car.color = "red"; redCarsNonFpShort :+= car}}
-
Spíše měl asi na mysly dlouhé výrazy. Zalomení dlouhého výrazu na 2-3 řádky se, alespoň u mě, čitelnosti moc nepomůže, možná spíš naopak. Pro někoho (včetně mě) je lepší, když se to rozloží na více menších kroků.
To je čistě věc vkusu/názoru a zkušenosti s tím daným jazykem. Ve FP neexistuje rozlišení výraz/příkaz, takže "jeden výraz" je všechno, i celý program je "jeden výraz". Pojmenovávat mezivýsledky je možný, ale mně to přijde většinou zbytečný:
red_cars = cars |> Enum.filter(&(&1[:id]==XXXX)) |> Enum.map(&(Map.put(&1,:color,:red)))
red_cars = cars
|> Enum.filter(&(&1[:id]==XXXX))
|> Enum.map(&(Map.put(&1,:color,:red)))
cars_with_id = cars |> Enum.filter(&(&1[:id]==XXXX))
red_cars = cars_with_id |> Enum.map(&(Map.put(&1,:color,:red)))
-
Spíše měl asi na mysly dlouhé výrazy. Zalomení dlouhého výrazu na 2-3 řádky se, alespoň u mě, čitelnosti moc nepomůže, možná spíš naopak. Pro někoho (včetně mě) je lepší, když se to rozloží na více menších kroků.
Ale pokud se to rozdeli na vice radku, tak pak v podstate korespenduje radek s krokem. Naopak zavadeni pomocnych promennych, ktere se nasledne ihned pouziji prave jednou me prijde jako obfuskace kodu.
-
Dlouhé řádky také nepoužívám - mám softlimit někde kolem 65 znaků.
To už víme, máš malý monitor :) Dneska je normální vidět na šířku 120 znaků najednou.
Tak uveď důvod, k čemu jsou dobré řádky programu delší než 80 znaků. Zhoršuje to čitelnost - oko se na tak dlouhém řádku prostě neudrží.
Už jsi někdy přemýšlel o tom, proč se noviny sází do sloupečků?
K tomuhle ;D
for (printf("1+1 Kalkulačka\n");3==scanf("%f%1[+-*/]%f",&x,&z,&y);printf("%.3f %c %.3f = %.3f\n",x,z,y,'+'==z?x+y:'-'==z?x-y:'*'==z?x*y:y&&'/'==z?x/y:NAN)) while ('\n'!=getchar());
Noviny jsou čtivo na jedno použití, knihy s trvalejší hodnotou se do sloupečků netisknou. Nezačínal jsi náhodou s FORTRANem?
-
Noviny jsou čtivo na jedno použití, knihy s trvalejší hodnotou se do sloupečků netisknou. Nezačínal jsi náhodou s FORTRANem?
Velkoformátové knížky se samozřejmě sází taky do sloupečků. S trvalostí to nemá co dělat.
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
Programator, ackoliv je v ramci IT sveta v podstate delnicka profese, tak jiste znaky analytickeho mysleni potrebuje.
Rekl bych, ze obecne bude mezi programatory relativne malo lidi vericich (ve smyslu nejakeho nabozenstvi).
A ano, programator je clovek ktery rad vidi nejaky cil, konec, reseni problemu. Na rozdil od tech mene prirodnich vet kde 50 popsanych stranek nemusi znamenat vubec zadny zaver(ackoliv penize z grantu prozrany byly)
V zasade s tebou souhlasim. Ten bipolar zustava nekterym az do pozdni dospelosti. Je to urcitym zpusobem i profesne omezujici nebot takovy clovek neni prilis schopen nejakeho kompromisu nebo sebekritiky.
Ale nechapu co se ti na prirodnich vedach tak nezamlouva. Vetsinou tam je nejaky vysledek jako ze na zaklade statistiky a pozorovanim se dana zvirata chovaji protoze... Nebo posledni vysledky optickych jevu kolem cerne diry jsou taky dost cool. A vice konkretni jsou vyzkumy z fyziky a chemie.
Kdysi davno kdyz jeste matematika byla na skolach modlou a jistym politickym nastrojem presvedcovani vericich na ateismus se matematika radila mezi prirodni vedy (na me byvale skole jsem kvuli tomu byl taky nejak prirazen k teto sekci neb socialismus skolstvi stale obchazi...)
Matematika spise je hromadou nejakych myslenkovych konstrukci(zjednodusenych) ktere by mely popisovat realne deje ve svete. Spis se jedna o velice abstraktni jazyk na popisovani deju. Avsak umele vytvoreny.
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
Je to opet historicky relikt osobniho technologickeho vyvoje. Omezeni nazvu souboru na 8-12 pismen, omezeni delky procedur a funkci, omezeni systemova (ano fakt jsme se jeste na VS ucili delat kratsi zdrojaky kvuli mistu), ciselne kody chyb. A tyhle zvyky si lide nesou i do 21 stoleti.
Proti tomu stoji javovsky prilis popisne:
space.earth.my_city.street32.olddirtyhouse.someflat.uglyroom.lightswitch.tinybutton je fakt maso. A nedivim se ze javisti se kolikrat bez idecka co jim to graficky rozlozi neobejdou, nebot proste kouknu v editoru a vidim tady moc nefunguje.
-
Proti tomu stoji javovsky prilis popisne:
space.earth.my_city.street32.olddirtyhouse.someflat.uglyroom.lightswitch.tinybutton je fakt maso. A nedivim se ze javisti se kolikrat bez idecka co jim to graficky rozlozi neobejdou, nebot proste kouknu v editoru a vidim tady moc nefunguje.
- Kolik programátorů ve Windows je potřeba na vyměnění žárovky?
- 472. Jeden napíše WinGetLightBulbHandle, jeden napíše WinQueryStatusLightBulb, jeden napíše WinGetLightSwitchHandle...
-
Extrémy se najdou na obou stranách, jistě. A proto je potřeba používat rozum a cit.
Mimochodem, to "kouknu do editoru a vidím" u složitějšího softu stejně nefunguje, vidím kousíček a abych to pochopil, stejně musím nastudovat, co se děje kolem. A tomu rozumné popisné názvy sakra pomáhají. Orientaci v cizím kódu řeším skoro každý den.
Nevidím důvod se např. u byznys aplikací (které živí většinu vývojářů) omezovat na 80 znaků. Pokud někdo není ochoten zaplatit 3k za fullhd monitor, nevěřím, že se programováním živí.
Jo, např. linuxový kernel má historický limit 80 znaků a správci to tvrdě vyžadují, přímo ve zdrojácích kernelu je na to skript, který štábní kulturu kontroluje. Jenže kernelí kód vzorem přehlednosti a čitelnosti kódu není ani náhodou...
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
Je to opet historicky relikt osobniho technologickeho vyvoje. Omezeni nazvu souboru na 8-12 pismen, omezeni delky procedur a funkci, omezeni systemova (ano fakt jsme se jeste na VS ucili delat kratsi zdrojaky kvuli mistu), ciselne kody chyb. A tyhle zvyky si lide nesou i do 21 stoleti.
Jsou snad mé ukázky použití funkce s více parametry nečitelné?
Nedělám to kvůli místu, ale kvůli čitelnosti. Už jsem psal, že oko má při čtení problém na řádcích, které mají víc než 65 znaků. Kratší zdrojáky dělám kvůli SRP. Číselné kódy chyb systémových funkcí konvertuji na výjimky s popisným textem.
Ještě nějaký problém?
Proti tomu stoji javovsky prilis popisne:
space.earth.my_city.street32.olddirtyhouse.someflat.uglyroom.lightswitch.tinybutton je fakt maso. A nedivim se ze javisti se kolikrat bez idecka co jim to graficky rozlozi neobejdou, nebot proste kouknu v editoru a vidim tady moc nefunguje.
Evidentně je zde porušován Déméteřin zákon. To snad ani nemá cenu číst a tomu vývojáři bych to omlátil o hlavu. V Javě se má psát objektově.
-
Nevidím důvod se např. u byznys aplikací (které živí většinu vývojářů) omezovat na 80 znaků. Pokud někdo není ochoten zaplatit 3k za fullhd monitor, nevěřím, že se programováním živí.
Šířka monitoru s tím vůbec nesouvisí. Texty s kratšími řádky je obvykle možné číst pohybem očí shora dolů. U textů s dlouhými řádky je nutno hýbat očima (nebo i hlavou) zleva doprava a zpět. To velmi unavuje a tedy i snižuje produktivitu.
-
V tomhle mi teda přijde lepší využít defaultní parametry:
content = file_get_contents(
filename="source.txt",
usePath=False,
context=stream_context_create(),
offset=-1,
maxle=100000,
)
Pokud to daný jazyk umožňuje, je to OK. V PHP si musim pomoct jinak.
-
Spíše měl asi na mysly dlouhé výrazy. Zalomení dlouhého výrazu na 2-3 řádky se, alespoň u mě, čitelnosti moc nepomůže, možná spíš naopak. Pro někoho (včetně mě) je lepší, když se to rozloží na více menších kroků.
Ale pokud se to rozdeli na vice radku, tak pak v podstate korespenduje radek s krokem. Naopak zavadeni pomocnych promennych, ktere se nasledne ihned pouziji prave jednou me prijde jako obfuskace kodu.
Pokud někdo ty pomocné proměnné nazve pom1, pom2, foo, bar a dalšími nesmysly, tak je to obfuskace. Pokud jsou ty názvy snadno čitelné, diktovatelné a sémanticky správné, tak naopak čitelnosti pomáhají.
-
Pokud někdo ty pomocné proměnné nazve pom1, pom2, foo, bar a dalšími nesmysly, tak je to obfuskace. Pokud jsou ty názvy snadno čitelné, diktovatelné a sémanticky správné, tak naopak čitelnosti pomáhají.
Myslíš, že v tomhle příkladu http://forum.root.cz/index.php?topic=12452.msg153091#msg153091 pomáhají čitelnosti? Mně přijde nejčitelnější ten prostřední (s rozumným odsazením, tady mi to oproti textarea ujelo)
Ten poslední mi nepřijde moc čitelný, protože si musím zbytečně všímat, že cars_with_id je použito na druhém řádku a ty dva řádky si v hlavě spojit do jednoho a to je zdržení. Jo, kdyby ty fce byly složitější, tak by se to dalo pochopit, že by pojmenování možná pomohlo.
-
Mimochodem, to "kouknu do editoru a vidím" u složitějšího softu stejně nefunguje, vidím kousíček a abych to pochopil, stejně musím nastudovat, co se děje kolem. A tomu rozumné popisné názvy sakra pomáhají. Orientaci v cizím kódu řeším skoro každý den.
Každá třída by měla být "kouknu do editoru a vidím". Minimum skrytých závislostí a pokud možno vše mít popsáno v rozhraní, které by zároveň mělo být co nejštíhlejší. Veřejné objekty a metody jsou implicitně také součástí rozhraní třídy, proto by se i jimi mělo šetřit.
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
Programator, ackoliv je v ramci IT sveta v podstate delnicka profese, tak jiste znaky analytickeho mysleni potrebuje.
Rekl bych, ze obecne bude mezi programatory relativne malo lidi vericich (ve smyslu nejakeho nabozenstvi).
A ano, programator je clovek ktery rad vidi nejaky cil, konec, reseni problemu. Na rozdil od tech mene prirodnich vet kde 50 popsanych stranek nemusi znamenat vubec zadny zaver(ackoliv penize z grantu prozrany byly)
V zasade s tebou souhlasim. Ten bipolar zustava nekterym az do pozdni dospelosti. Je to urcitym zpusobem i profesne omezujici nebot takovy clovek neni prilis schopen nejakeho kompromisu nebo sebekritiky.
Ale nechapu co se ti na prirodnich vedach tak nezamlouva. Vetsinou tam je nejaky vysledek jako ze na zaklade statistiky a pozorovanim se dana zvirata chovaji protoze... Nebo posledni vysledky optickych jevu kolem cerne diry jsou taky dost cool. A vice konkretni jsou vyzkumy z fyziky a chemie.
Kdysi davno kdyz jeste matematika byla na skolach modlou a jistym politickym nastrojem presvedcovani vericich na ateismus se matematika radila mezi prirodni vedy (na me byvale skole jsem kvuli tomu byl taky nejak prirazen k teto sekci neb socialismus skolstvi stale obchazi...)
Matematika spise je hromadou nejakych myslenkovych konstrukci(zjednodusenych) ktere by mely popisovat realne deje ve svete. Spis se jedna o velice abstraktni jazyk na popisovani deju. Avsak umele vytvoreny.
Jaký druh na Zemi je nejcennější? Člověk a jeho výtvory, protože evoluce ani za miliardy let dinosauřího druhového panování, nic podobného nevytvořila. A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
-
Pokud někdo ty pomocné proměnné nazve pom1, pom2, foo, bar a dalšími nesmysly, tak je to obfuskace. Pokud jsou ty názvy snadno čitelné, diktovatelné a sémanticky správné, tak naopak čitelnosti pomáhají.
Myslíš, že v tomhle příkladu http://forum.root.cz/index.php?topic=12452.msg153091#msg153091 pomáhají čitelnosti? Mně přijde nejčitelnější ten prostřední (s rozumným odsazením, tady mi to oproti textarea ujelo)
Ten poslední mi nepřijde moc čitelný, protože si musím zbytečně všímat, že cars_with_id je použito na druhém řádku a ty dva řádky si v hlavě spojit do jednoho a to je zdržení. Jo, kdyby ty fce byly složitější, tak by se to dalo pochopit, že by pojmenování možná pomohlo.
Ten prostřední mi také přijde nejčitelnější. Také proto, že se jedná o fluent interface, u kterého je to jaksi standardní zápis. Jen to odsazení bych zvolil 4 mezery, resp. jeden tab.
-
Výraz space.earth.my_city.street32.olddirtyhouse.someflat.uglyroom.lightswitch.tinybutton je špatně proto, že ukazuje na špatný objektový návrh,
volání této metody v míste použití by mělo vypadat switchButton() a vše by mělo být převedeno na zasílání zpráv objektům uvnitř toho řetězce volání. Kontext by měl být zřejmý z obsahu těla metody, kde to volání je použito.
Když dítě skládá kostky lega, taky ho nezajímá, z čeho ty kostky jsou vyrobeny. To zajímá jen výrobce těch kostek.
-
Já jako programátor to vidím obdobně. Vysvětlovat neprogramátorovi jaký to je je jako vysvětlovat to psovi. Bude na tebe čumět a může ti chvilku i připadat že ti rozumí ale pak ti dojde že je to jen blbej pes a že tomu nemůže rozumět, je to marný.
Ptát se jaké je to být programátorem je ptát se jaké je to být bohem. Jedinej způsob jak pochopit jaký je být programátorem je stát se jím. Pokud máš rád filozofování o smyslu a fungování věcí, tak programování tě nakopne na úplně novej level. Ale je to nebezpečný, může se ti stát že tě to tak chytne že tě už nebude zajímat nic jinýho. :-)
Pokud tě chytne programování tak, že tě nebude zajímat nic jiného, tak pak hrozí, že ti psycholožka (https://cz.linkedin.com/in/ren%C3%A1ta-heged%C3%BC%C5%A1ov%C3%A1-273b3979) diagnostikuje poruchu osobnosti :-(
Viz třeba zde: http://www.jikos.cz/~mikulas/komix/FREESOFT.GIF
-
Myslim si, ze vetsina programatoru ma (pri nejmensim na zacatku kariery) sklony k bipolarnimu vnimani sveta.
Programator zpravidla nezna "je tam trochu vody". Programator formuluje otazky jako:
je tam nejaka voda? (1 kapka staci k odpovedi ano).
je ta sklenice plna(neexistuje pro nej skoro plna)? Zkratka tak, aby bylo mozne odpovidat ano - ne stejne jako mu to vyhodnocuje pocitac.
Programator, ackoliv je v ramci IT sveta v podstate delnicka profese, tak jiste znaky analytickeho mysleni potrebuje.
Rekl bych, ze obecne bude mezi programatory relativne malo lidi vericich (ve smyslu nejakeho nabozenstvi).
A ano, programator je clovek ktery rad vidi nejaky cil, konec, reseni problemu. Na rozdil od tech mene prirodnich vet kde 50 popsanych stranek nemusi znamenat vubec zadny zaver(ackoliv penize z grantu prozrany byly)
V zasade s tebou souhlasim. Ten bipolar zustava nekterym az do pozdni dospelosti. Je to urcitym zpusobem i profesne omezujici nebot takovy clovek neni prilis schopen nejakeho kompromisu nebo sebekritiky.
Ale nechapu co se ti na prirodnich vedach tak nezamlouva. Vetsinou tam je nejaky vysledek jako ze na zaklade statistiky a pozorovanim se dana zvirata chovaji protoze... Nebo posledni vysledky optickych jevu kolem cerne diry jsou taky dost cool. A vice konkretni jsou vyzkumy z fyziky a chemie.
Kdysi davno kdyz jeste matematika byla na skolach modlou a jistym politickym nastrojem presvedcovani vericich na ateismus se matematika radila mezi prirodni vedy (na me byvale skole jsem kvuli tomu byl taky nejak prirazen k teto sekci neb socialismus skolstvi stale obchazi...)
Matematika spise je hromadou nejakych myslenkovych konstrukci(zjednodusenych) ktere by mely popisovat realne deje ve svete. Spis se jedna o velice abstraktni jazyk na popisovani deju. Avsak umele vytvoreny.
A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
Vy jste z Prognostickeho ustavu?
-
ono svym zpusobem je magicke treba i sledovat bleskovy sach nabo Carlsonna (Kasparova) kdy pri simultance obchazi 50 stolu a jednim pohledem behem vteriny ma okamzity vhled (intuice ?, zkusenost ?) do situace a voli tah (neverim ze drzi v pameti 50 rozehranych paralelnich partii) ... bude to zase jime mysleni ale nejak mne to napadlo ... jiny pohled na svet ma matematik, inzenyr, programator
ale asi jde o to, neztratit ze zretele a mit stale pred sebou to hlavni, a to je problem solving, test reality ?
matematik to ma asi tezsi kdyz v ramci axiomu dospeje k nejakemu elegantnimu reseni, dokonce ho dokaze, ale v prirode takove reseni neexistuje (cili je realne neexistujici)
-
A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
Vy jste z Prognostickeho ustavu?
Z nejakyho ustavu urcite...
-
A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
Vy jste z Prognostickeho ustavu?
Z nejakyho ustavu urcite...
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
-
A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
Vy jste z Prognostickeho ustavu?
Z nejakyho ustavu urcite...
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
"Predpoklada se" a "Panuje predstava".
Retorika na Prognostak presne sedi. Jestli jste skutecne tam odsud, tak mate slusnou sanci bejt prezident. Nebo Vas zhaftnou v Kantonalni bance s kufrem na penize a taky se muzete stat krtkem GRU v CIA. Proste Vas asi ceka celkem zajimavej zivot ;-)
-
A jak se zdá, na vrcholu této evoluce bude myslící stroj, který nebude potřebovat okolní svět, a svět si vytvoří sám v sobě. Superinteligence bude autistická.
Vy jste z Prognostickeho ustavu?
Z nejakyho ustavu urcite...
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
Tohle celkem spolehlivě vyvrátila už Ada Lovelace.
Experti v IBM postavili nejvýkonnější superpočítač na světě, a chtěli od něj vyřešit otázku, která trápí lidstvo od nepaměti: "Existuje Bůh?"
Vložili do jeho paměti všechny dostupné informace o všech náboženstvích světa, o záhadných a nadpřirozených jevech, o vědě, přírodě i Vesmíru, prostě úplně všechno co by se dané otázky mohlo nějak týkat.
Potom spustili program k jejich zpracování. Počítač začal přežvykovat data, třídil je, porovnával, vyřazoval, zase se k vyřazeným vracel a novu je zkoumal, pracoval nepřetržitě celé dny, týdny, měsíce...
Když už jeho tvůrci ztráceli naději a chystali se ho vypnout, Program náhle skončil, a na monitoru se objevil nápis:
"Teď už ano!"
-
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
Že nás zničí, se objevuje tak akorát v hollywoodských filmech. Ve vědeckých kruzích je poměrně silná představa technologické singularity, kdy budou stroje tak inteligentní, že nedokážeme ani odhadnout, co se vlastně stane.
-
filozof a programator jsou docela protihlehle pristupy,
Nejsou. Vyšší levely programování se např. skrze logiku a vytváření modelů parádně potkávají nejenom s moderní analytickou filosofií, ale třeba i s některými partiemi dávné filosofie. Dobře zhuštěné seznámení s Aristotelem by pro žádného programátora nebylo na škodu. Každý programátor pořád dokola řeší problémy typu obecné vs. konkrétní, dokonce i substance vs. akcident, akorátže neví, že se tomu tak říká a že se jeho problémy (v trochu jiné podobě samozřejmě) řešily už před dvěma tisíci lety. Jestliže mu někdo na střední nezáživně a nevýstižně vykládal o sporu o univerzálie, zbytečně je odsouzen část z omylů opakovat, jako třeba když si myslí, že nutně musí existovat něco jako třída (~ substance), jinak se svět propadne v chaos :)
Spíš než v tom, o čem píšeš, je problém s lidma, kteří o filosofii nic neví a představují si, že filosofie = bezbřehé nekontrolovatelné a neověřitelné plkání o πčovinách. To není pravda, aspoň ne obecně.
Speciální případ přesahu mezi programováním, filosofií a (matematickou) logikou jsou pak věci jako teorie typů, kategorií, sémantika apod. kde je to úplně zřejmé.
Každému, kdo programuje, doporučuju knížky Peregrina. Sice mi ten člověk nesedí lidsky (znám ho osobně z univerzity), ale píše o filozofii dost zajímavě a pro "normální lidi".
-
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
Že nás zničí, se objevuje tak akorát v hollywoodských filmech. Ve vědeckých kruzích je poměrně silná představa technologické singularity, kdy budou stroje tak inteligentní, že nedokážeme ani odhadnout, co se vlastně stane.
Inteligence, ale není nekonečná, protože rychlost zpracování informací je omezena rychlostí světla. S mnohem zajímavějším konceptem, kdysi přišel Lem. Vytvořil představu myslícího stroje, který měl rozšířené vnímání časového úseku, který považujeme za právě teď, ten se mu roztáhl na několik minut, což mu umožňovalo předvídat budoucnost v rámci toho jeho právě teď.
-
slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ? nejde mi ani tak o vysvetlovani jednotlivych paradigmat, natoz syntaxe, spis o nejake "kulhajici"zobecneni neprenosnych ? zkusenosti za roky co se venujete programovani ? asi to nejde co ? ja vim ze nikdy umet programovat nebudu tak bych chtel jen zazit ten pohled na svet Vasima ocima ...
Dobrý programátor myslí abstraktně (matematicky). Není náhoda, že nejlepší vědci, již přispěli (akademicky) ke "computer science", se rekrutovali z oborů jako matematika (příkladů je přehršel), fyzika (Feynman), ale i (analytická) filozofie (Robinson).
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem. Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum (jak jsme si zde na fóru mohli nedávno přečíst, takový dement by neměl dělat ani v PHP).
-
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
Že nás zničí, se objevuje tak akorát v hollywoodských filmech. Ve vědeckých kruzích je poměrně silná představa technologické singularity, kdy budou stroje tak inteligentní, že nedokážeme ani odhadnout, co se vlastně stane.
Inteligence, ale není nekonečná, protože rychlost zpracování informací je omezena rychlostí světla. S mnohem zajímavějším konceptem, kdysi přišel Lem. Vytvořil představu myslícího stroje, který měl rozšířené vnímání časového úseku, který považujeme za právě teď, ten se mu roztáhl na několik minut, což mu umožňovalo předvídat budoucnost v rámci toho jeho právě teď.
Jo, a psal zprávy do novin, nejmenovalo se to 137 sekund? To není myslící stroj, na to je potřeba inteligence na úrovni slepice hrající Tic-tac-toe. Ale i ta dokáže spoustu lidí porazit, poslechni si jak Novotný vyprávěl o cestě Fešáků do Ameriky a o jedné speciální ZOO ;D
Žádné myslící stroje nebudou. Jenom lidé stále sílící závislostí na nich zblbnou natolik, že budou ještě blbější než ty počítače. Všichni, ne jenom konzumní většina jako dnes.
-
Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem. Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum
Debil může pojmenovat rozhraní ICompare a bude v klidu :) Dříve se psalo ICompare, dnes se píše Comparable, ale je to jedno a to stejné, stejný druh Hungarian Notation.
-
Žádné myslící stroje nebudou.
Pokud se podaří dodržet Moorův zákon (to není vůbec jisté), tak myslící počítač s IQ 100 tady bude ještě před rokem 2050.
-
Moorův zákon může trvat nekonečně dlouho, protože je ceně za tranzistor a ta je dána obchodní politikou. Klidně se to může prodávat i zadarmo, navíc do roku 2050 možná skončí monetární systém. Spíše než o ceně by to mělo být o vynaložené hmotě a energii, čemuž by teoreticky měla odpovídat i cena. Pak bych to viděl černěji, určitě ne až do roku 2050.
A pokud bychom Moorův zákon předefinovali na zmenšování tranzistoru, tak už jsme skončili nebo skončíme hodně brzo. Proces 10nm se odkládá, 7 a 5nm je zatím jen v laboratořích bez valné naděje na komercializaci. Při těchto rozměrech vstupují do hry kvantové jevy, zejména tunelový jev a samozřejmě "obyčejné" interference.
Takže já žádný průlom v roce 2045 neočekávám na rozdíl od snílků jako Ray Kurzweil.
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem.
Pokud dodržuješ pravidlo Tell, don't ask, tak ti moc prostoru pro immutable metody nezbývá. Ale i tak: Máš snad něco proti názvům metod seek(), find() nebo search(), které používám u kolekcí?
Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum (jak jsme si zde na fóru mohli nedávno přečíst, takový dement by neměl dělat ani v PHP).
FUD.
Aerable je stejným nesmyslem jako IArea. Základem pro tvorbu názvů rozhraní nemá být substantivum, ale verbum. Stačí se podívat na to, co rozhraní obsahuje: Seznam hlaviček metod - tedy schopností, které má daný objekt splňovat. Z toho se dá odvodit název rozhraní. Pokud je tam třeba metoda print(), tak to rozhraní pojmenuji Printable a implementuji ho ve třídě Rectangle apod.
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
Bylo by dobré, kdyby sis ten odstavec dočetl až do konce. Snad v něm najdeš odpověď.
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
Bylo by dobré, kdyby sis ten odstavec dočetl až do konce. Snad v něm najdeš odpověď.
dočetl hned napoprvé, konkrétní odpověď tam skutečně není
-
Aerable je stejným nesmyslem jako IArea.
...
tak to rozhraní pojmenuji Printable
Logicky z toho vyplývá že Printable je stejným nesmyslem jako IPrint.
-
Aerable je stejným nesmyslem jako IArea.
...
tak to rozhraní pojmenuji Printable
Logicky z toho vyplývá že Printable je stejným nesmyslem jako IPrint.
Nikde není v požadavcích napsáno, co má ten obdélník umět. Tak jsem si vymyslel metodu print(), protože mě v tu chvíli nic lepšího nenapadlo. Pokud nepotřebuje umět nic, není ani nutné žádné rozhraní - to je občas také užitečné, pokud si vystačíš se standardními metodami, které umí každý objekt.
-
Aerable je stejným nesmyslem jako IArea.
...
tak to rozhraní pojmenuji Printable
Logicky z toho vyplývá že Printable je stejným nesmyslem jako IPrint.
Nikde není v požadavcích napsáno, co má ten obdélník umět. Tak jsem si vymyslel metodu print(), protože mě v tu chvíli nic lepšího nenapadlo. Pokud nepotřebuje umět nic, není ani nutné žádné rozhraní - to je občas také užitečné, pokud si vystačíš se standardními metodami, které umí každý objekt.
píše se tam o objektu, který "má plochu", např. obdélník, takže jaký je správný název metody a rozhraní?
-
píše se tam o objektu, který "má plochu", např. obdélník, takže jaký je správný název metody a rozhraní?
Co znamená "má plochu"? Slovo "má" vyjadřuje vlastnicví, nikoli schopnosti. Plochu si v konstruktoru uložíš do privátních atributů, na to rozhraní nepotřebuješ. Název metody ani rozhraní tedy nelze odvodit. Obdélník, který má plochu, ji klidně může mít a nepotřebuje k tomu žádné rozhraní. Místo rozhraní pak napíšeš slovo Object a všichni budou spokojeni.
-
píše se tam o objektu, který "má plochu", např. obdélník, takže jaký je správný název metody a rozhraní?
Co znamená "má plochu"? Slovo "má" vyjadřuje vlastnicví, nikoli schopnosti. Plochu si v konstruktoru uložíš do privátních atributů, na to rozhraní nepotřebuješ. Název metody ani rozhraní tedy nelze odvodit. Obdélník, který má plochu, ji klidně může mít a nepotřebuje k tomu žádné rozhraní. Místo rozhraní pak napíšeš slovo Object a všichni budou spokojeni.
co když chci např. spočítat celkovou plochu kolekce dvourozměrných objektů?
-
co když chci např. spočítat celkovou plochu kolekce dvourozměrných objektů?
To ale nebylo v původním zadání a právě sis vymyslel to "co když".
Tak si vymysli název metody pro výpočet plochy libovolného objektu (např. calculate() nebo areaCalculate()) a z toho si odvoď název rozhraní (např. Calculable nebo AreaCalculable).
Bohužel pro "výpočet plochy" nemáme v češtině jedno slovo. Slovo "plocha" může mít více významů a nelze ho tedy otrocky přeložit na "area". Podobně ten anglický výraz má i další významy, než jen výpočet plochy.
-
Tak já nevím, že s těma názvama tak naděláte. Každé lepší EDI má v sobě refaktorizaci a když blbě zvolím název, tak to za 5 sekund opravím hned na všech místech. A o tomto to přesně je, diskuze se vedou o nevýznamných detailech, ale o archtektonických aspektech výstavby aplikací tady žádné přínostné diskuze nejsou.
-
Tak já nevím, že s těma názvama tak naděláte. Každé lepší EDI má v sobě refaktorizaci a když blbě zvolím název, tak to za 5 sekund opravím hned na všech místech. A o tomto to přesně je, diskuze se vedou o nevýznamných detailech, ale o archtektonických aspektech výstavby aplikací tady žádné přínostné diskuze nejsou.
Pro přejmenování metody v rozhraní musím mít hodně dobrý důvod, jinak tím mohu ohrozit značnou část projektu. Co když na třídách, které na něm závisí, někdo jiný udělal změny? Někdo další ten merge musí udělat a nemusí to být zrovna triviální operace.
Kromě toho tím "svým refaktorováním" porušuješ OCP.
-
Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.
Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...
Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem.
Pokud dodržuješ pravidlo Tell, don't ask, tak ti moc prostoru pro immutable metody nezbývá. Ale i tak: Máš snad něco proti názvům metod seek(), find() nebo search(), které používám u kolekcí?
Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum (jak jsme si zde na fóru mohli nedávno přečíst, takový dement by neměl dělat ani v PHP).
FUD.
Aerable je stejným nesmyslem jako IArea. Základem pro tvorbu názvů rozhraní nemá být substantivum, ale verbum. Stačí se podívat na to, co rozhraní obsahuje: Seznam hlaviček metod - tedy schopností, které má daný objekt splňovat. Z toho se dá odvodit název rozhraní. Pokud je tam třeba metoda print(), tak to rozhraní pojmenuji Printable a implementuji ho ve třídě Rectangle apod.
Areable jsi tehdy použil ty...
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
Příčestí - HavingArea
-
Aerable je stejným nesmyslem jako IArea.
...
tak to rozhraní pojmenuji Printable
Logicky z toho vyplývá že Printable je stejným nesmyslem jako IPrint.
Nikde není v požadavcích napsáno, co má ten obdélník umět. Tak jsem si vymyslel metodu print(), protože mě v tu chvíli nic lepšího nenapadlo. Pokud nepotřebuje umět nic, není ani nutné žádné rozhraní - to je občas také užitečné, pokud si vystačíš se standardními metodami, které umí každý objekt.
píše se tam o objektu, který "má plochu", např. obdélník, takže jaký je správný název metody a rozhraní?
Správně je computed property area a v jazyce, který to neumožňuje, metoda area() v rozhraní HavingArea (případně WithArea, což je PP)
-
Aerable je stejným nesmyslem jako IArea.
Areable jsi tehdy použil ty...
No a?
-
Ja bych potreboval potkat nejakou rozumnou implementaci Fuckable, ale asi je to uzkej profil...
-
Žádné myslící stroje nebudou.
Pokud se podaří dodržet Moorův zákon (to není vůbec jisté), tak myslící počítač s IQ 100 tady bude ještě před rokem 2050.
1. Moorův zákon se týká počtu součástek na jednom čipu, to nemá s myšlením nic společného. Navíc už je poněkud pasé, další zmenšování se nedaří a zvětšovat čipy se nevyplatí.
2. Pokud jsi měl na mysli růst vůkonu počítačů, tak by mě zajímalo z čeho a jak jsi odvodil potřebný výkon pro IQ 100.
-
Aerable je stejným nesmyslem jako IArea.
Areable jsi tehdy použil ty...
No a?
Ukázals zásadní neznalost angličtiny a diskvalifikoval ses pro další diskuzi. Jinak nic.
-
Aerable je stejným nesmyslem jako IArea.
Areable jsi tehdy použil ty...
No a?
Ukázals zásadní neznalost angličtiny a diskvalifikoval ses pro další diskuzi. Jinak nic.
No a?
-
Každému, kdo programuje, doporučuju knížky Peregrina.
Jo. Taky jsem ho tady už několikrát doporučoval. Asi nejzajímavější a širšímu okruhu nejsrozumitelnější český filosof jakého jsem zatím potkal.
Jako člověka ho neznám, takže nemůžu soudit.
-
Každému, kdo programuje, doporučuju knížky Peregrina.
Jo. Taky jsem ho tady už několikrát doporučoval. Asi nejzajímavější a širšímu okruhu nejsrozumitelnější český filosof jakého jsem zatím potkal.
Jako člověka ho neznám, takže nemůžu soudit.
Až bych řekl, že jediný srozumitelný.
-
No dnes ale panuje představa, že myslící stroje nás zničí. Jenže budou nám natolik vzdáleny, že pro ně nebudeme představovat žádnou konkurenci. Předpokládá se, že jakmile k nim dospějeme, budou jejich schopnosti růst geometrickou řadou.
Že nás zničí, se objevuje tak akorát v hollywoodských filmech. Ve vědeckých kruzích je poměrně silná představa technologické singularity, kdy budou stroje tak inteligentní, že nedokážeme ani odhadnout, co se vlastně stane.
Inteligence, ale není nekonečná, protože rychlost zpracování informací je omezena rychlostí světla. S mnohem zajímavějším konceptem, kdysi přišel Lem. Vytvořil představu myslícího stroje, který měl rozšířené vnímání časového úseku, který považujeme za právě teď, ten se mu roztáhl na několik minut, což mu umožňovalo předvídat budoucnost v rámci toho jeho právě teď.
Jo, a psal zprávy do novin, nejmenovalo se to 137 sekund? To není myslící stroj, na to je potřeba inteligence na úrovni slepice hrající Tic-tac-toe. Ale i ta dokáže spoustu lidí porazit, poslechni si jak Novotný vyprávěl o cestě Fešáků do Ameriky a o jedné speciální ZOO ;D
Žádné myslící stroje nebudou. Jenom lidé stále sílící závislostí na nich zblbnou natolik, že budou ještě blbější než ty počítače. Všichni, ne jenom konzumní většina jako dnes.
Myslící stroje už jsou, a protože jsou chytřejší než my, tak o nich nevíme :-)
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
HasArea
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
HasArea
To je blbě, to není příčestí.
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
HasArea
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
HasArea
To je blbě, to není příčestí.
Na příčestí s8ru. Souhlasím s http://verraes.net/2013/09/sensible-interfaces/ . Raději to udělám pěkné a čitelné než se za každou cenu držet blbých nestandardizovaných "standardů". Radši budu mít HasTimestamp než Timestampable. Radši něco pojmenuju "x má Obsah" než "x je mající Obsah", sorry, I no speak americano.
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
Zvykneš si :)
-
Až bych řekl, že jediný srozumitelný.
To ne. Jsou různí zajímaví autoři, ale často specializovaní na něco, co třeba lidi moc nezajímá. Mám docela rád třeba Sokola, Koháka (primárně náboženství a etika, která moc lidi nezajímá) i Maternu (TIL - úplná specialitka, která nezajímá vůbec žádné laiky). Ti jsou pro mě jako laika srozumitelní dobře. Opačný extrém je pak třeba Útěcha z ontologie, čemuž bych moc rád porozuměl, protože tuším, že by mi to hodně dalo, ale nedal jsem ani prvních deset stránek ;) Tak jsem se aspoň zamiloval do Bondyho novel, když ty odborný věci nedám :)
-
Pro informatika by ještě mohl být zajímavý třeba Ivan Havel a knížky o umění od Jaroslava Nešetřila. Ten první mě ale moc za srdce nechytl a k tomu druhýmu jsem se ještě nedostal...
-
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
Zvykneš si :)
Asi nezvyknu. Dobře, Servable zní blbě, tak přinejhorším IsServer nebo CanServe, ale HasServer je nepochopitelné. Vždyť to žádný server nemá.
-
Aerable je stejným nesmyslem jako IArea.
jak je to teda správně?
HasArea
To je blbě, to není příčestí.
Na příčestí s8ru. Souhlasím s http://verraes.net/2013/09/sensible-interfaces/ . Raději to udělám pěkné a čitelné než se za každou cenu držet blbých nestandardizovaných "standardů". Radši budu mít HasTimestamp než Timestampable. Radši něco pojmenuju "x má Obsah" než "x je mající Obsah", sorry, I no speak americano.
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
Zvykneš si :)
Timestampable ti asi poradil Kit. Ale HasTimestamp je taky blbost, i když menší.
-
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
Zvykneš si :)
Asi nezvyknu. Dobře, Servable zní blbě, tak přinejhorším IsServer nebo CanServe, ale HasServer je nepochopitelné. Vždyť to žádný server nemá.
Tak to dopadá, když jména vymýšlí někdo, kdo neumí anglicky.
-
No přiznám se, že na HasServer (http://hackage.haskell.org/package/servant-server-0.4.4.6/docs/Servant-Server.html) si nějak zvyknout nemůžu.
Zvykneš si :)
Asi nezvyknu. Dobře, Servable zní blbě, tak přinejhorším IsServer nebo CanServe, ale HasServer je nepochopitelné. Vždyť to žádný server nemá.
Servable zní blbě, protože -able implikuje trpný rod. Rozhraní většinou znamenají "capable of VP" a podle slovesného rodu oné VP se vybere pojmenování (mnohdy stačí nechat jen hlavní sloveso s příslušnou koncovkou).
-
Pro informatika by ještě mohl být zajímavý třeba Ivan Havel a knížky o umění od Jaroslava Nešetřila. Ten první mě ale moc za srdce nechytl a k tomu druhýmu jsem se ještě nedostal...
když už jsme u toho, tak ještě Vopěnka (to je filozofie smíchaná s logikou, geometrií, teorií množin a navíc vše je psané hezkou češtinou)
-
když už jsme u toho, tak ještě Vopěnka (to je filozofie smíchaná s logikou, geometrií, teorií množin a navíc vše je psané hezkou češtinou)
Pravda pravdoucí, na toho jsem zapomněl. Respektive nezmínil, protože jsem od něho zatím nic nečetl (jo, vím, obrovská kulturní mezera, měl bych to dohnat!)
-
ono svym zpusobem je magicke treba i sledovat bleskovy sach nabo Carlsonna (Kasparova) kdy pri simultance obchazi 50 stolu a jednim pohledem behem vteriny ma okamzity vhled (intuice ?, zkusenost ?) do situace a voli tah (neverim ze drzi v pameti 50 rozehranych paralelnich partii) ... bude to zase jime mysleni ale nejak mne to napadlo ... jiny pohled na svet ma matematik, inzenyr, programator
Txe zeptej přímo jeho.
http://www.ceskatelevize.cz/ivysilani/1093836883-na-plovarne/20236816026-na-plovarne-s-garry-kasparovem
-
Ja bych potreboval potkat nejakou rozumnou implementaci Fuckable, ale asi je to uzkej profil...
Třeba já mám poruchu osobnosti, tak pohlavní styk neprovozuji.