Příspěvky

616

Vývoj / Re:Použití kódu ze zaměstnání v osobním projektu

« kdy: 28. 01. 2017, 14:39:24 »

Děkuji za odpovědi.

Svůj projekt bych chtěl zveřejnit pod Open source licencí.
A jak píše javaman (), přeci nejde popřít získanou znalost.
Zvláště, když obojí vzniká v krátkém časovém rozdílu a obojí bude mít, ač se budu snažit sebevíce, stejný rukopis.
Také jsem přispěl do firemního projektu kousky z toho svého, jelikož mě to nevadí.
Oba projekty jsou v jiném jazyce, takže o přímou kopii nejde.

Konkurenční produkt to také není, takže zaměstnavatele to přímo poškodit nemůže.
V případě, že za ním přijdu, a na problém upozorním, se vystavuji riziku, že to zatrhne.

Dám asi konkrétní příklad.
Když budu totožný prvek řídit v obou projektech, v odlišném jazyce, tak stejně musím nastudovat totožnou dokumentaci a postup vymyslím pouze jeden.
Dochází zde ke kolizi?

Jak jsem již psal, přeci nebudu vynalézat kolo nadvakrát.
A v osobním projektu, tedy ten co bude vidět a může mě reprezentovat do budoucna, přeci nebudu používat tu horší variantu.

U nás v ČR je autorsky chráněn jen konkrétní kód. Je-li to v jiném jazyce, není co řešit, nejedná se o porušení žádného zákona ani smlouvy (nejde o zaměstnanecké nebo odvozené dílo).

617

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

« kdy: 28. 01. 2017, 13:25:07 »

I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.

Jo, channel tam vlastně sehraje úlohu toho "asynchronizačního bufferu". Pořád je to ale to "něco navíc", co musím někde vytvořit, má to (aspoň teoreticky) nějakou režii, nějak to komplikuje kód. Přijde mi daleko přímočařejší kód, který když nechci, aby blokoval, tak nedělám nic, když chci, aby blokoval, tak prostě čekám na místě, dokud nedojde k události. Vytvářet thread/rutinu/channel kvůli jednomu volání je prostě (pocitově) pro mě míň estetické

...ale to jsme se dostali do zbytečných detailů, myslím, že si rozumíme a nejsme v žádném sporu

Možná mi něco nedocvaklo, ale blokování asynchronního volání (resp. čekání) má taky režii, potřebuju třeba semafor nebo tak něco, ne? Jinak bych to asi fakt ukončil, v konečném důsledku ten zápis v obou případech závisí na konkrétním jazyce a příslušném běhovém prostředí.

618

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

« kdy: 28. 01. 2017, 13:12:49 »

Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).

Souhlas, dík za doplnění. Nic to ale nemění na tom, že:

Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".

To mi přijde trochu subjektivní, protože i blokování je věc runtimu, ale pravda je, že příslušný kód je trochu přímočařejší. I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.

619

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

« kdy: 28. 01. 2017, 12:56:42 »

To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.

Myslel jsem prostředky toho jazyka samotného. Pokud mám fci, která blokuje, třeba http_get_content(uri), tak programátorskými prostředky (uvnitř jazyka) z ní asynchronní neudělám jinak než (pseudokód):

Kód: [Vybrat]

start_thread(fun(){
  content = http_get_content(uri)
  do_something_with(content)
})
this_is_not_blocked(x,y,z)

Maximálně bych mohl mít v jazyce nějakou spešl konstrukci, která se vnitřně přeloží nějak speciálně, třeba samostatná vlákna runtime simuluje v rámci jednoho vlákna, ale to je z louže pod okap... Ta situace s asynchronností jako defaultem mi prostě přijde lepší (YMMV).

Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).

620

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

« kdy: 28. 01. 2017, 12:44:02 »

To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.

Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".

To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.

621

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

« kdy: 27. 01. 2017, 16:40:09 »

OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.

Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.

622

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

« kdy: 27. 01. 2017, 16:00:27 »

Predavanie "sprav" v smalltalku je tiez len posielanie objektov do inych objetov cez selectory.  Inac povedane volanie metod s parametrami.  Nie je to ziadna objektova magia. Je to to iste co napriklad aj v C++ .

Ty to schytáš Ale tak když už tomu nerozumíš, je lepší mlčet (univerzální pravidlo)... #doesNotUnderstand ;-)

Čekal jsem, kdo na tu krávovinu zareaguje

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.

Ty si nedáš říci .. no tak mi naprogramuj následující tři prográmky (ve smalltalku téměř one-linery) v C++:

1) Zeptej se uživatele na string, a pošli objektu Foo zprávu (nebo v C++ terminologii zavolej na objektu Foo metodu), která se jmenuje stejně jako zadaný String. Vypiš uživateli výsledek volání, pokud Foo danou metodu nemá, vypiš uživateli, že to neumí..

2) Za běhu zjisti, jaké zprávy Foo umí přijímat

3) Stejně jako 1, ale pokud Foo zprávu neumí, za běhu přidej implementaci, která vrátí String "Jsem tu nová", a opakuj volání zprávy na Foo

4) (to už se netýká zpráv, ale jen tak pro zajímavost): Za běhu zjisti, jaké třídy je Foo instance, a jaké další podtřídy tato třída má.

Pod řešení mi můžeš napsat, že zprávy v C++ a ve Smalltalku jsou to same.

Jde o jednoho z místních trolů, takže bych radil nereagovat.

623

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

« kdy: 27. 01. 2017, 14:53:32 »

Predavanie "sprav" v smalltalku je tiez len posielanie objektov do inych objetov cez selectory.  Inac povedane volanie metod s parametrami.  Nie je to ziadna objektova magia. Je to to iste co napriklad aj v C++ .

Ty to schytáš Ale tak když už tomu nerozumíš, je lepší mlčet (univerzální pravidlo)... #doesNotUnderstand ;-)

Čekal jsem, kdo na tu krávovinu zareaguje

624

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

« kdy: 27. 01. 2017, 14:18:37 »

...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.

"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

Podle mě je Smalltalk čistý OOP jazyk, a v praxi se používá velice příjemně.

Souhlas, ale není to mainstream. Moje chyba, napsal jsem to blbě, měl jsem na mysli, že se v "čisté" podobě nevyskytuje v mainstreamu. V ObjC je hezké předávání zpráv, ale zase má primitivní typy (protože to je trošku rozšířené C), Swift není dynamický a vlastně mě z těch "velkých" jazyků nenapadá žádný, co by byl (ve smyslu OOP).

625

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

« kdy: 27. 01. 2017, 13:51:17 »

...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.

"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

626

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

« kdy: 27. 01. 2017, 12:53:59 »

Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.

A o tom to je: Problém nemusí vůbec být v monádách, ale ve vystižení jejich myšlenky. Měl jsem s tím problém na všech školách - jestliže přesně nevystihnul podstatu myšlenky (a to je přece smyslem), nefungovalo to.
Takže (nejen pro mě) by se hodilo uvést nějaký zdroj, který přesně vystihuje podstatu (jako neznalý jej nerozpoznám). Upozorňuju, že právě na Wikipedii jsou uvedeny příklady bez jakéhokoliv úvodu do syntaxe, takže jsou nečitelné. I na ten elixírový příklad jsem musel docela čumět, než jsem odhadnul, co by to asi tak mohlo dělat.

U (různých typů) monád je problém, že krom pár abstraktních pravidel je nic na první pohled nespojuje, např. seznamy vs. kontinuace vs. maybe. Proto v nich asi tolik lidí plave a uniká jim sjednocující myšlenka. Ostatně já sám jsem znal monády dávno z matematiky, ale v kódu jsem je používal intuitivně. Až když mě rozmach FP donutil podívat se na něj blíže, došly mi všechny souvislosti. Možná je prostě lepší naučit se používat konkrétní typy monád a na abstraktní aparát za nimi se vykašlat, protože většina kodérů jej stejně nikdy v té abstraktní rovině nevyužije.

627

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

« kdy: 26. 01. 2017, 23:47:34 »

který mainstreamový funkcionální jazyk klacky pod nohy hází?

to už tu bylo probíráno mnohokrát.

před chvílí se v jiném vlákně někdo ptal na dijkstrův algoritmus, tak třeba to

https://rosettacode.org/wiki/Dijkstra%27s_algorithm#Haskell

tam se musí používat monády jen protože FP.

Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.

628

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

« kdy: 26. 01. 2017, 23:42:39 »

A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

S mnoha body souhlasím. OOP dogmatismus je ještě horší. Snaha o čistě FP kód má racionální základ. Snaha o čistě OOP kód je jen čistý fanatismus.

Erlang je v některých ohledech přísnější než Elixir. Elixir má narozdíl od Erlangu mutable proměnné. Což považuji za výhodu.

Nechci vyvolávat flame. Berte to jako názor čistého praktika původem z trochu jiného oboru. Možná mi něco uniká.

Osobně ani nevím, co by "čisté OOP" mělo přesně být. Nicméně být "praktikem" se většinou vyplácí.

629

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

« kdy: 26. 01. 2017, 21:33:27 »

Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.

OK. V dogmatickém FP je to nepostradatelný koncept. Nabízí se otázka, jestli dogmatické FP nevytváří víc problémů než řeší. Argument s formálním dokazováním správnosti FP programů má váhu jen u programů, kde tu správnost skutečně někdo dokazuje. Dost se mi líbí přístup jazyka Elixir, který zde byl zmíněn. Umožňuje psát FP stylem, ale nehází zbytečně klacky pod nohy.

K tomu se nějak vyjadřovat nechci, ostatně sám FP používám jen v jazycích, které jsou převážně OO, a jsem zastáncem spíš pragmatického přístupu. Nicméně zrovna u monád mám pocit, že se poměrně rozšířily i mimo čisté FP (byť se jim většinou říká jinak nebo nijak).

630

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

« kdy: 26. 01. 2017, 20:56:23 »

Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.

Těžko se k tomu hledá motivace. Monády řeší problém, který neexistuje. Většina vědních oborů považuje jednoduchá řešení za elegantní a hledá právě jednoduchá řešení. SW inženýrství je výjimka. Vyžívá se v uměle složitých řešeních jednoduchých problémů. Proto je pro spoustu lidí jeho studium nepřístupné.

Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.