Programátorův pohled na svět

[Mirek Prýmek]

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

[Reklama]

[Kit]

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.

[Unknown]

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...

[Ivan Nový]

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ě.

[Mirek Prýmek]

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:

Kód: [Vybrat]

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):

Kód: [Vybrat]

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

Kód: [Vybrat]

.done(()=>{...}).fail(()=>{...})

Jinak, i ten filtr je v Elixiru daleko čitelnější:

Kód: [Vybrat]

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:

Kód: [Vybrat]

red_cars = cars |> Enum.filter(&(&1[:id]==XXXX)) |> Enum.map(&(&1[:color]=:red))


[Reklama]

[Mirek Prýmek]

Errata:

Kód: [Vybrat]

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í...

[pepa]

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

[fos4]

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.

[Kit]

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.

[Wololo]

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.

[Wololo]

Pro upresneni, posledni dva kroky, 15. a 16. jsou vlastne zavadne funkce, ktere nemaji v programu "koupit pivo" co delat, jelikoz koupit neznamena konzumovat .... =)

[andy]

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

[podlesh]

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]

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 ?

[Ivan Nový]

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 :-)))