Programátorův pohled na svět

lopata

Re:mysleni pana Programatora
« Odpověď #105 kdy: 08. 01. 2016, 12:07:36 »
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.


lopata

Re:mysleni pana Programatora
« Odpověď #106 kdy: 08. 01. 2016, 12:15:58 »
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.

lopata

Re:Programátorův pohled na svět
« Odpověď #107 kdy: 08. 01. 2016, 12:53:57 »
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.

lopata

Re:Programátorův pohled na svět
« Odpověď #108 kdy: 08. 01. 2016, 13:18:13 »
lojza: Automatické přistání řízené počítačem zvládal Concorde v roce 1969, ten počítač byl analogový.

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.

lopata

Re:Programátorův pohled na svět
« Odpověď #109 kdy: 08. 01. 2016, 13:19:41 »
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.


Re:mysleni pana Programatora
« Odpověď #110 kdy: 08. 01. 2016, 15:38:14 »
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

lopata

Re:Programátorův pohled na svět
« Odpověď #111 kdy: 08. 01. 2016, 17:18:13 »
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.

Re:mysleni pana Programatora
« Odpověď #112 kdy: 08. 01. 2016, 19:12:58 »
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í?!

Re:mysleni pana Programatora
« Odpověď #113 kdy: 08. 01. 2016, 19:24:16 »
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.

Re:mysleni pana Programatora
« Odpověď #114 kdy: 08. 01. 2016, 20:08:38 »
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í)

noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:mysleni pana Programatora
« Odpověď #115 kdy: 08. 01. 2016, 20:30:02 »
... Č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 vypadaji, ze bezi v jinem vlaknu.

Nevim, jestli to uplne souvisi, ale treba LiveScript ma zajimavou feature - backcally, ktere umoznuji nezanorovani callbacku.
Kód: [Vybrat]
do
  data <-! $.get 'ajaxtest'
  $ '.result' .html data
  processed <-! $.get 'ajaxprocess', data
  $ '.result' .append processed

JS:
Kód: [Vybrat]
$.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 :).

Re:mysleni pana Programatora
« Odpověď #116 kdy: 08. 01. 2016, 21:16:07 »
Nikdy jsem to nepouzil, ale 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, 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á...

Lama

Re:mysleni pana Programatora
« Odpověď #117 kdy: 08. 01. 2016, 22:18:35 »
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.

Kit

Re:mysleni pana Programatora
« Odpověď #118 kdy: 08. 01. 2016, 22:29:30 »
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.

čumil

Re:mysleni pana Programatora
« Odpověď #119 kdy: 08. 01. 2016, 22:39:48 »
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.