Příspěvky

1606

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 15:44:16 »

A tiez v praxi sa nedokazuje, ci je algoritmus formalne spravny, ale ci sa chova spravne pre urcite vstupy a vystupy.
Formalne dokazovanie sa robi tak v NASA? Mozno ani tam nie?

Pro určité vstupy to dokázat lze. Pro libovolný vstup to pro (netriviální) programy dokázat nelze.

No, a proto nepíšu obecné algoritmy pro libovolný vstup, ale konkrétní algoritmy pro konkrétní množinu dat.

Čímž se dostáváme zpět k tomu, že statickým typováním si určuju tu množinu, že jo.

1607

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 15:25:29 »

Jediné dynamické jsou data z venku. Což ale právě ten můj systém nemůže rozbít, protože vše je jasně definované.

Nebo mi něco uniká?

Uniká ti tohle: https://en.wikipedia.org/wiki/Halting_problem

A jak to souvisí s reálným světem reálného OOP v Javě? Nechci nic za chodu měnit! Víš, kolik jsem viděl lopat, které debugovaly kód, který se jim měnil? Při každém průchodu tam měly něco jiného, protože byly cool a dynamické věci jsou přece víc agilní.

Rád ti to vysvětlím. Už v roce 1936 Alan Turing dokázal, že nexistuje obecný algoritmus, který by řešil problém zastavení pro všechny vstupy všech programů na Turingově stroji. Možná víš, že Java je Turing complete programovací jazyk. Prakticky to znamená, že nelze rozhodnout jestli je nějaký (netriviální) program (v Javě) správný a bude fungovat pro jakýkoliv vstup. Tvoje tvzení:

Jediné dynamické jsou data z venku. Což ale právě ten můj systém nemůže rozbít

je nesmysl, který tvrdíš, protože neznáš základy IT.

Přehlédl jsi v tom Alanově vyjádření to "obecný algoritmus".

1608

Vývoj / Re:Build aplikace přes více strojů podle recepisu

« kdy: 02. 02. 2017, 15:20:41 »

Já nechci instalovat jednu aplikaci na jeden stroj.
Já chci instalovat jednu aplikaci, která musí běžet na více strojích. Typicky nějaká webová aplikace skládající se z databázového serveru, webového serveru, loadbalanceru, memcache, cronu, beanstalku, etc

Na to by byl ideální docker a docker composer, případně kubernetes. Ale chápu, že nemusí vyhovovat každému.

Supr, mejm představám nejblíže odpovídá Dockerfile. Ale ten taky (alespoň myslím) vytvoří jen jeden server. A navíc bych si to představoval nevirtualizované.

Chtěl bych napsat konfigurační script, ve kterém uvedu, že databázový server má běžet na této IP, a toto jsou k ní přístupy; http server na jiné IP, s těmito přístupy, ... atd. Konfigurační script plus Build script a spustit nějakým builderem.

Uměl bych to udělat pomocí Saltu, ale přijde mi to trochu znásilnění toho nástroje.

A tak se ptám, zda neexistuje něco jiného.

1609

Vývoj / Re:Build aplikace přes více strojů podle recepisu

« kdy: 02. 02. 2017, 14:14:23 »

Já nechci instalovat jednu aplikaci na jeden stroj.
Já chci instalovat jednu aplikaci, která musí běžet na více strojích. Typicky nějaká webová aplikace skládající se z databázového serveru, webového serveru, loadbalanceru, memcache, cronu, beanstalku, etc

1610

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 02:58:16 »

Osobne, ked pocujem slovo "makro", jezia sa mi vlasy. Znamena to, ze jazyk nie je dostatocne pouzitelny  a potrebuje nejake pretechnizovane barlicky aby generoval kod za programatora.

Ten závěr je velmi podařený. To je asi tak jako bych řekl, že z editorů se mi ježí vlasy na hlavě, protože generují text za programátora (který klidně mohl text do souboru nabušit na první dobrou pomocí catu).

Makra jsou velmi silný a tím i nebezpečný nástroj. Není to žádná berlička pro chromého, naopak jazyky bez maker jsou oproti těm s makry trochu belhající se...

Makra sa vacsinou pouzivaju na to, aby programatori mohli pouzivat nie zrovna zrejme konstrukcie, ktore sa ani nemusia podobat povodnemu jazyku. Clovek neznaly, ake makra tam niekno naprplal vidi kod a ide si oci vyocit, ze ako to dofrasa moze vobec fungovat . Nebodaj, ked je este v makre chyba...  Zly koncept na urovni copy-paste programovania.

Asi ti nevadí, že IF-THEN-ELSE je (defakto) makro, že ne?

1611

Vývoj / Build aplikace přes více strojů podle recepisu

« kdy: 02. 02. 2017, 01:51:42 »

Do určité míry znám Ansible, Puppet, Salt. Slouží k tomu, abych mohl popsat konfiguraci serveru, a pak ji snadno spustit na více mašinách.

To mě inspirovalo: Existuje nástroj, ve kterém si definuju aplikaci, a tu pak nějakým builderem spustím?

Příklad:
Jednoduchá webová aplikace. Ta potřebuje apache na stroji 10.0.0.1, kód aplikace strahuje z gitu z 10.0.0.2, připojuje se k databázi, která běží na stroji 10.0.0.3 - plus hesla, klíče, etc.
Po stáhnutí z gitu se musí provést ještě nějaký build (maven, composer, npm, ...), vytvoření adresářů, etc.

Takže bych očekával, že si tuto konfiguraci nějak zadefinuju do souboru, a pak spustím build tento soubor, a on si vleze na všechny stroje, a udělá tam co potřebuju.

Používá se na to ten Salt, Puppet, Ansible?
Existují na to nějaké jiné nástroje?
Znáte něco, můžete doporučit? Články, postupy, cokoliv co si myslíte, že je zajímavé.

Díky.

1612

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 00:19:41 »

Tento argument naprosto nechápu.

Zkusim to vysvetlit jeste jinak. Programovaci jazyky se obecne vyvijeji smerem k vyssi abstrakci (lepsi reprezentaci umyslu programatora), na ukor omezeni toho, co a jak efektivne (z hlediska provadeni pocitacem) lze v jazyce zapsat. Design patterns nejsou krok na teto ceste, to je ta potiz. Objasnit se to da pomoci historicke paralely:

Predstav si program v assembleru, tam jsou jen instrukce skoku (goto). Pred mnoha lety se tak programovalo bezne. A ted si predstav, ze nekdo napise knihu "GOTO patterns". A bude treba rikat, mame "if pattern", to je skok za kus kodu po testovani podminky, nebo "while(1) pattern", to je nepodmineny skok zpet jako smycka, nebo "break pattern", to je skok mimo smycku, atd.

Ale to se nestalo (tedy, v prvni fazi ano, viz https://en.wikipedia.org/wiki/Structured_program_theorem). K cemu naopak doslo, ze se tyto vzory dostaly do programovacich jazyku primo jako abstrakce. Proto dnes piseme if, nikoli "pouzivame if pattern". A pocitac vi, co je "if". Duvod to tak delat je, ze cist kod v assembleru je tezsi - je tezsi proste neustale uvedomovat si treba "aha, tady programator pouzil break pattern". Ti, co umi cist assembler, samozrejme takove vzory vidi, to neni problem. Ale i tak je to kognitivni zatez.

Moc pěkné přirovnání.

1613

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 19:37:18 »

Udělejme si v tom pořádek:
1. FP si nepůjčuje věci z jiných paradigmat. FP je paradigma samo o sobě.
2. Co si půjčuje z jiných paradigmat jsou tak maximálně jazyky.
3. Haskell je pure funkcionální, a z imperativního světa si tam fakt půjčuje pouze zápis některých monád a to kdo ví zda vůbec.
4. Opovrhování jinýmy paradigmaty je jen tvá fantazie. Nikde jsem nic takového nenaznačil.

Zopakuji co jsem chtěl říct: To, že vývojáři nepoužívají FP je jen otázka zvyku. FP rozhodně není neintuitivní.

Len ten zvyk trva uz nejako dlho, pricom su nonstop pokusy o pretlacenie FP do mainstreamu. A FP je taka dokonala paradigma, ze potrebuje aj objektove a proceduralne konstrukcie  inak je to hracka pre matematikov.

Vzhledem k tomu, že za 40let co existuje OOP (ať se vrátíme k tématu topicu) se programátoři nenaučili OOP používat a dál to patlají procedurálně, jsem optimistou.
To by ostatně mohlo odpovědět na tvou otázku, proč že prej FP není v mainstreamu. Těch důvodů je pochopitelně více, a hlavně bych je hledal v technické oblasti, ale jedním z nich je skutečnost, že třeba v Haskellu funkcionálně programovat musíš. Zatímco v Javě objektově nikoliv.

1614

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 15:14:33 »

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

Ze pokial prejdeme od skolskych prikladov do realneho sveta, multiparadigmovitost je vsadepritomna.

Jak to souvisí s tvrzením, že FP je neintuitivní.

Ze FP si poziciava veci z inych paradigiem aby bolo intuitivnejsie? T.j. opovrhovanie inymi paradigmami je sranie si do vlastneho hniezda.

Udělejme si v tom pořádek:
1. FP si nepůjčuje věci z jiných paradigmat. FP je paradigma samo o sobě.
2. Co si půjčuje z jiných paradigmat jsou tak maximálně jazyky.
3. Haskell je pure funkcionální, a z imperativního světa si tam fakt půjčuje pouze zápis některých monád a to kdo ví zda vůbec.
4. Opovrhování jinýmy paradigmaty je jen tvá fantazie. Nikde jsem nic takového nenaznačil.

Zopakuji co jsem chtěl říct: To, že vývojáři nepoužívají FP je jen otázka zvyku. FP rozhodně není neintuitivní.

1615

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 14:27:47 »

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

Ze pokial prejdeme od skolskych prikladov do realneho sveta, multiparadigmovitost je vsadepritomna.

Jak to souvisí s tvrzením, že FP je neintuitivní.

1616

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 13:58:49 »

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

A nebo prostě trvá, než si na to lidi zvyknou.

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

To už je jiné téma.

1617

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 13:29:04 »

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

A nebo prostě trvá, než si na to lidi zvyknou.

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

1618

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 13:24:32 »

Takze vezmime si konfiguraciu aplikacie, ktora sa kazdych x minut obnovuje. A budem mat 50 nekonzistentnych konfiguracnych objektov, lebo pan riesi Http request a filesystem. Alebo spravi sa singleton a budem mat konfiguraciu na jednom mieste, pre vsetkych rovnaku.

Dalsi priklad mam rozhranie rs232, tam nie je httprequest alebo databaza, problem je vsak, ze je len jedno. Bud vymyslim neviem ake zamykanie cez 50 instancii, alebo si proste spravim singleton.

Potrebujem nieco serializovat von do nejakeho mrdkoveho suboru, co nema http request ani databazu, a je potrebne aby sa do neho nezapisovalo z 50 miest. Takze bud spravim sialene zamykanie cez 50 instancii, alebo spravim singleton. Pripadne sa zahram na to, ze som jouda a singleton nepoznam a ten isty objekt odovzdavam vo vsetkych metodach. To je potom "super", zbytocne to tam zavadzia.

Dalsi relevantny pripad. Chcem sa vyhnut "statickej" triede, lebo je to vlastne zkripleny objekt a ja chcem normalny, pouzijem singleton.

Ked robim webku pre jouda sro v php, mozno singletony nie su treba. Ale pri roznych IRL aplikaciach potreba nastava. U vas toho polku zariadi webserver a ani o tom neviete.  Ja osobne, kde mozem, pouzijem framework, co sa o instancie stara za mna. Ale su pripady, ked nemozem, lebo kodim zrovna lib-ku, co ma mat zavislost iba na java api. Tam singleton vyuzijem.

Tak to jsou zrovna hodně špatné příklady - to, že potřebujete číst jedinou konfiguraci, používat jedno spojení a komunikovat přes jeden sériák, neznamená, že je musíte vyrobit jako jedináčka. Objekt, který s nimi pracuje, je má dostat při inicializaci nebo spuštění akce (nebo od někoho, koho zná). Co se stane, když budete mít více konfiguráků? Když přidáte další sériák? Když budete komunikovat s 3 servery?
Toto řešení mi spíš zavání globálními odkazy přes třídu. Antivzor znemožňující testování, zvyšující coupling a zabordelující aplikaci!

Že nejdou třídní věci dát do třídy, protože je Java zprasená, je věcí druhou.

To je toho prskania, musel som si ocistit macbook. Ked budem potrebovat 3 seriaky, odstranim singleton z objektu a spravim si pool. A zrovna ten pool bude tiez singleton. To da kurevsku praci zmazat tri riadky. A ze je globalny objekt pre aplikaciu, ano je, o tom je, to je feature.

Musim ocenit, ze viete googlit ale:

• Nevola sa to triedne, ale objektovo-orientovane programovanie. Je to objektoch, triedy nestastne vymyslel Kay.
• Testovanie singleton neztazuje, staci si nastavit pri testovani singleton. Skobinujem ho so vzorom strategy a voila, da sa to menit za hocico! Brutalne tazka robota. Rozne mock objekty a  netrivialne zavislosti testovanie komplikuju viac. Btw unit testy ako su dnes vymyslene nie su objektove.
• Viac konfigurakov v jednej aplikacii? To je naco dobre?

Ale jo, mi ti to neberem. Taky jsem to tak dělal. Pak jsem přišel na to, že to není dobrý nápad. To je prostě všechno.

1619

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 12:51:01 »

IMHO ale nejlepsi je trochu se naucit Haskell. Cloveka to trochu hodi do vody, a je z toho pomerne zrejme, proc se v FP veci delaji jak se delaji; v jinych jazycich, ktere jenom prejimaji prvky FP (treba Scala nebo Java) mohou nektere veci vypadat podivne. No a kdyz ziskas trochu zkusenost, uvidis sam, jak se ty veci, na ktere se ptas, daji realizovat pres skladani funkci, bude ti to proste pripadat prirozene a naopak pristup pres tridy a interfacy uvidis jako zbytecne tezkopadny. (Bohuzel se to tezko sdeluje..)

Takové nešťastně řečené. Haskell má třídy (říká jim typy) a interface (říká jim třídy). A je to dost důležitý a užívaný koncept. Snad ten nejdůležitější v Haskellu, který jej odlišuje od ostatních FP jazyků. Ne nadarmo se používá úslový: "následuj typy".

1620

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 22:50:35 »

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.

Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají Alespoň člověk ví, co tam bude za lidi.

Singleton sa nezvykne pouzivat, ak je k dispozicii dependency injection framework. Ale inac neviem si predstavit, ako by sa riesila jedna jedina zdielana instancia pre celu aplikaciu v plain jave ... 

Omluv můj sarkasmus: já si nedovedu představit situaci, kdy bych potřeboval sdílenou instanci pro celou aplikaci.

HTTP request, FileSystem, DB connection - u ničeho z toho nepovažuji za žádoucí vynucovat si jen jednu jedinou instanci by design.

Takze vezmime si konfiguraciu aplikacie, ktora sa kazdych x minut obnovuje. A budem mat 50 nekonzistentnych konfiguracnych objektov, lebo pan riesi Http request a filesystem. Alebo spravi sa singleton a budem mat konfiguraciu na jednom mieste, pre vsetkych rovnaku.

Dalsi priklad mam rozhranie rs232, tam nie je httprequest alebo databaza, problem je vsak, ze je len jedno. Bud vymyslim neviem ake zamykanie cez 50 instancii, alebo si proste spravim singleton.

Potrebujem nieco serializovat von do nejakeho mrdkoveho suboru, co nema http request ani databazu, a je potrebne aby sa do neho nezapisovalo z 50 miest. Takze bud spravim sialene zamykanie cez 50 instancii, alebo spravim singleton. Pripadne sa zahram na to, ze som jouda a singleton nepoznam a ten isty objekt odovzdavam vo vsetkych metodach. To je potom "super", zbytocne to tam zavadzia.

Dalsi relevantny pripad. Chcem sa vyhnut "statickej" triede, lebo je to vlastne zkripleny objekt a ja chcem normalny, pouzijem singleton.

Ked robim webku pre jouda sro v php, mozno singletony nie su treba. Ale pri roznych IRL aplikaciach potreba nastava. U vas toho polku zariadi webserver a ani o tom neviete.  Ja osobne, kde mozem, pouzijem framework, co sa o instancie stara za mna. Ale su pripady, ked nemozem, lebo kodim zrovna lib-ku, co ma mat zavislost iba na java api. Tam singleton vyuzijem.

Nesmysl. Takhle bych to nikdy neudělal. V žádném z uvedených příkladů bych nepoužil singleton, není nutný. A rozhodně bych neměl problémy které popisuješ.

HTTP Request nebo FS jsem jen uváděl jako příklad, který by někoho mohl napadnout, že by se na to rozhodně singleton použil. Tak holt jsi přišel s půl tuctem dalších, stejně validních, u kterých tvrdíš, že je to nastopro kandidát na singleton. OK, já s tebou nesouhlasím.