Dědičnost dnes

Re:Dědičnost dnes
« Odpověď #795 kdy: 01. 02. 2017, 23:39:50 »
Stále čekám na funkcionální implementaci Dijkstry. Nemusíte navrhovat ani implementovat. Stačí poslat odkaz.
Google dneska nefunguje, nebo považuješ zboje za personální asistentku? :))


JS

Re:Dědičnost dnes
« Odpověď #796 kdy: 01. 02. 2017, 23:40:47 »
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.

BoneFlute

  • *****
  • 1 841
    • Zobrazit profil
Re:Dědičnost dnes
« Odpověď #797 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í.

balki

Re:Dědičnost dnes
« Odpověď #798 kdy: 02. 02. 2017, 01:40: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.

Trosku to mate pomylene a velmi ste si o vzoroch necitali. Vzory nie su od toho, aby suplovali prikazy, alebo napomahali zlym rieseniam. Taketo vase "vzory" s goto by boli ihned zavrhnute.
To ani nie je mozne nazvat vzorom, taku hlupost by ste pomocou pattern language ani neopisali.

Vzory su od toho, aby sa z nich casom stali idiomy avsak opisuju inteligentne riesenia. OOP vzory su v aspektotovo-orientovanom programovani idiomy. AOP sa da realizovat aj miernym pozmenenim funkcionalneho. Jediny problem, ze funkcionalnemu programovaniu aj s AOP podivnost stale zostava aj jeho priaznivci su nadalej nieco ako crossfit-vegani.

balki

Re:Dědičnost dnes
« Odpověď #799 kdy: 02. 02. 2017, 02:05:47 »
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.


BoneFlute

  • *****
  • 1 841
    • Zobrazit profil
Re:Dědičnost dnes
« Odpověď #800 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?

Re:Dědičnost dnes
« Odpověď #801 kdy: 02. 02. 2017, 08:05:40 »
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.
Proto jsem psal, že jsou makra nebezpečná - spousta lidí se jejich silou nechá zlákat a řeší jimi buď vůbec neexistující problémy nebo věci, které by se daly řešit jinak. Rule of thumb je, že makro by se mělo použít jenom tam, kde řešení pomocí funkcí neexistuje, nebo by bylo výrazně míň elegantní.

Ale není pravda, že makra jsou zlo. Naopak, často významně chybí. Například ve staticky typovaných jazycích, které nemají makra ani dostatečně flexibilní/efektivní/elegantní pozdní vazbu je problém s RPC. Tak se to řeší tím, že se napíše úplně standalone "generátor stubu", což je de facto ad hoc vytvořený macro processor, který se dá použít jenom na ten jeden účel. Čili výrazně horší řešení než obecná makra, použitelná i na cokoli jiného.

Makra se dají použít i na optimalizaci - pokud vím, že něco platí v době běhu, můžu toho využít a např. nějaký kód pomocí makra nahradit NOOPem apod.

Překladač Elixiru zas dělal (nevím, jestli to ještě platí) takovou srandičku, že jakousi funkci zpracovávající unicode při překladu generoval přímo z aktuální specifikace. Prostě se při překladu stáhlo nějaké specifikační XMLko nebo co a na základě něj se vytvořila funkce pattern-matchující jednotlivé znaky (skupiny znaků? detaily si nepamatuju). Čili při překladu vznikl superaktuální kód, efektivnější než kdyby se v tom XMLku vyhledávalo za běhu. A to bez jakýchkoli berliček typu "generátor unicode stubu".

...protože správně použitá makra nejsou žádné berličky, právě naopak - pokud je nemám a hodila by se mi, musím se k nějaké berličce uchýlit.
« Poslední změna: 02. 02. 2017, 08:08:01 od Mirek Prýmek »

spasitel

Re:Dědičnost dnes
« Odpověď #802 kdy: 02. 02. 2017, 08:30:36 »
nasi C++ vyvojari delaji makra o sto sest. kdybych mel prevzit jejich kod, asi bych si nejspis hodil masli.

Re:Dědičnost dnes
« Odpověď #803 kdy: 02. 02. 2017, 08:33:30 »
Makra se dají použít i na optimalizaci - pokud vím, že něco platí v době běhu, můžu toho využít a např. nějaký kód pomocí makra nahradit NOOPem apod.
Pardon, samozřejmě "v době překladu".

ava

Re:Dědičnost dnes
« Odpověď #804 kdy: 02. 02. 2017, 09:55:06 »
A ještě pokud tomu dobře rozumím, tak "pravé" OOP je dynamické. Takže aplikaci zapnu a vyvíjím za chodu? Protože při každém volání metody jsem ji mohl předefinovat, ne? A fakt takhle někdo vyvíjí?

Ano, přesně takhle se programuje ve Smalltalku. Aplikace může neustále běžet (vlastně se ani moc nerozlišuje aplikace a IDE, při deployi se jen IDE zahodí), neustále je možné jí posílat třeba HTTP requesty, dám si breakpoint do nějakého handleru, zjistím, že se mi něco nelíbí, předefinuju metodu, zkusím ji ručně zavolat z debuggeru, OK, zkusím to znovu přes HTTP request, funguje, vyvíjím dál... žádné neustálé restarty, žádná dlouhá kola edit-compile-run-prepareContext-try-debug-edit jako v pravěku (bohužel pravěk v Javě stále trvá....)

gll

Re:Dědičnost dnes
« Odpověď #805 kdy: 02. 02. 2017, 10:09:41 »
Stále čekám na funkcionální implementaci Dijkstry. Nemusíte navrhovat ani implementovat. Stačí poslat odkaz.
Google dneska nefunguje, nebo považuješ zboje za personální asistentku? :))

řešení, která jsem vygooglil nejsou čistě FP. Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

v

Re:Dědičnost dnes
« Odpověď #806 kdy: 02. 02. 2017, 10:12:18 »
A ještě pokud tomu dobře rozumím, tak "pravé" OOP je dynamické. Takže aplikaci zapnu a vyvíjím za chodu? Protože při každém volání metody jsem ji mohl předefinovat, ne? A fakt takhle někdo vyvíjí?

Ano, přesně takhle se programuje ve Smalltalku. Aplikace může neustále běžet (vlastně se ani moc nerozlišuje aplikace a IDE, při deployi se jen IDE zahodí), neustále je možné jí posílat třeba HTTP requesty, dám si breakpoint do nějakého handleru, zjistím, že se mi něco nelíbí, předefinuju metodu, zkusím ji ručně zavolat z debuggeru, OK, zkusím to znovu přes HTTP request, funguje, vyvíjím dál...
neříká se tomu epicykl nebo tak nějak?

balki

Re:Dědičnost dnes
« Odpověď #807 kdy: 02. 02. 2017, 10:16:33 »
A ještě pokud tomu dobře rozumím, tak "pravé" OOP je dynamické. Takže aplikaci zapnu a vyvíjím za chodu? Protože při každém volání metody jsem ji mohl předefinovat, ne? A fakt takhle někdo vyvíjí?

Ano, přesně takhle se programuje ve Smalltalku. Aplikace může neustále běžet (vlastně se ani moc nerozlišuje aplikace a IDE, při deployi se jen IDE zahodí), neustále je možné jí posílat třeba HTTP requesty, dám si breakpoint do nějakého handleru, zjistím, že se mi něco nelíbí, předefinuju metodu, zkusím ji ručně zavolat z debuggeru, OK, zkusím to znovu přes HTTP request, funguje, vyvíjím dál... žádné neustálé restarty, žádná dlouhá kola edit-compile-run-prepareContext-try-debug-edit jako v pravěku (bohužel pravěk v Javě stále trvá....)

Co mate s tymi dlhymi kompilaciami a deploymi v jave. Take nieco som zazil akurat na uchylnom liferay, ale to je overengineered technologia z praveku.

Inkvizitor

Re:Dědičnost dnes
« Odpověď #808 kdy: 02. 02. 2017, 10:17:10 »
A ještě pokud tomu dobře rozumím, tak "pravé" OOP je dynamické. Takže aplikaci zapnu a vyvíjím za chodu? Protože při každém volání metody jsem ji mohl předefinovat, ne? A fakt takhle někdo vyvíjí?

Ano, přesně takhle se programuje ve Smalltalku. Aplikace může neustále běžet (vlastně se ani moc nerozlišuje aplikace a IDE, při deployi se jen IDE zahodí), neustále je možné jí posílat třeba HTTP requesty, dám si breakpoint do nějakého handleru, zjistím, že se mi něco nelíbí, předefinuju metodu, zkusím ji ručně zavolat z debuggeru, OK, zkusím to znovu přes HTTP request, funguje, vyvíjím dál... žádné neustálé restarty, žádná dlouhá kola edit-compile-run-prepareContext-try-debug-edit jako v pravěku (bohužel pravěk v Javě stále trvá....)

To není žádný pravěk, je to jiný přístup. Já dávám přednost klasickému vývoji editací zdrojového kód po důkladném rozvážení a distribuci změn pomocí VCS. Smalltalk mi přijde jako vaření guláše. Je to málo slaný? Přisol. Zároveň mi do hrnce někdo strká lžíci, neb má hlad, kráva se na přední straně ještě pase, zadní noha se jí už vaří. Spadlo z ní zezadu něco do hrnce? Nevadí, vem naběračku, vylov to ven, zamíchej, přidej majoránku a vaříme dál.

Může to fungovat, ale možná je i nějaký dobrý důvod, proč se to ve větším měřítku neujalo.

ava

Re:Dědičnost dnes
« Odpověď #809 kdy: 02. 02. 2017, 10:24:50 »
....
Jsou mi vcelku jedno názory lidí, co nemají zkušenost s oběma přístupy,