Dědičnost dnes

[javaman ()]

To už je každého problém, jestli si to zjistí. V nejhorším vymyslí kolo, ale rozumný člověk bude vynakládat síly jen na něco nového.

Nevím z kterého oboru máte to Phd., ale informatika to zcela jistě není. To co tu plácáte jsou nesmysly.

+1

[Reklama]

[zboj]

To už je každého problém, jestli si to zjistí. V nejhorším vymyslí kolo, ale rozumný člověk bude vynakládat síly jen na něco nového.

Nové staví na starém. Alespoň v tvrdých vědách.  Nevím z kterého oboru máte to Phd., ale informatika to zcela jistě není. To co tu plácáte jsou nesmysly. Neznáte rozdíl mezi složitostí a vyčíslitelností.

Vážně?

Z pohledu vyčíslitelnosti to není (obecně) pravda.
.......
Například Dijkstrův grafový algoritmus (abych byl konkrétní) je v FP stejně efektivní jako v OOP.

A? Jistě, šlo by napsat i složitost, vyčíslitelnost je ovšem obecnější pojem, který mi zde přišel vhodnější, když už se bavíme o FP (tj. o funkcích) a jejich algoritmické charakteristice. Hádat se o slovíčka vážně nehodlám.

[javaman ()]

Hádat se o slovíčka vážně nehodlám.

Rly?

[gll]

To už je každého problém, jestli si to zjistí. V nejhorším vymyslí kolo, ale rozumný člověk bude vynakládat síly jen na něco nového.

Nové staví na starém. Alespoň v tvrdých vědách.  Nevím z kterého oboru máte to Phd., ale informatika to zcela jistě není. To co tu plácáte jsou nesmysly. Neznáte rozdíl mezi složitostí a vyčíslitelností.

Vážně?

Z pohledu vyčíslitelnosti to není (obecně) pravda.
.......
Například Dijkstrův grafový algoritmus (abych byl konkrétní) je v FP stejně efektivní jako v OOP.

A? Jistě, šlo by napsat i složitost, vyčíslitelnost je ovšem obecnější pojem, který mi zde přišel vhodnější, když už se bavíme o FP (tj. o funkcích) a jejich algoritmické charakteristice. Hádat se o slovíčka vážně nehodlám.

Nechci se hádat o slovíčkách. Chci vidět to stejně efektivní FP implementaci.

[Kiwi]

A? Jistě, šlo by napsat i složitost, vyčíslitelnost je ovšem obecnější pojem, který mi zde přišel vhodnější, když už se bavíme o FP (tj. o funkcích) a jejich algoritmické charakteristice. Hádat se o slovíčka vážně nehodlám.

+ Čili typická zrcadlová perverze.
- Inverze.
+ Prosím?
- Inverze!
+ Nebo inverze, ano...

[Reklama]

[JS]

Já bych prostě řekl že cílem může být odbourat zbytečnou byrokracii, ale ne byrokracii úplně (tak by tomu bylo v ideálním světě, kde programátoři vytvářejí a skládají matematické abstrakce).

Ja beru slovo byrokracie za pejorativni, takze samozrejme zbytecnou, nepejorativni vyraz by byl asi "proces".

Kazdopadne, to mi pripomina jednu z mych jinych vyhrad vuci navrhovym vzorum, ktera je, ze i konceptualne je to pomylena myslenka. V podstate se ocekava, ze programatori budou ten vzor sami rozeznavat (a pripadne aplikovat) v kodu. Ale to je hloupe, to co chces je naucit ten vzor pocitac (definovat urcitou abstrakci), aby to lide delat nemuseli, protoze lidska prace je draha a vede k chybam.

Je to podobne prastene, jako kdyz Java nema makra (rekneme a la Lisp), protoze by to bylo "moc slozite", ale pak se podobne problemy resi generovanim kodu, coz je samozrejme horsi.

[Kamil Podlešák]

V podstate se ocekava, ze programatori budou ten vzor sami rozeznavat (a pripadne aplikovat) v kodu. Ale to je hloupe, to co chces je naucit ten vzor pocitac (definovat urcitou abstrakci), aby to lide delat nemuseli, protoze lidska prace je draha a vede k chybam.

Tento argument naprosto nechápu. Ano, když nahradíme programátory umělou inteligencí, tak lidskou práci nahradíme. To je ale zatím jenom budoucnost a programátoři stále musí analyzovat problémy i kód a dělat rozhodnutí. Můžeme to hodně usnadňovat na všech stranách, hodně pomůže posunutí na vyšší úroveň (jako jsme se posunuli od návrhového vzoru "volání podprogramu"), ale právě to základní jádro (rozhodování, volba) tam stále je a počítač to naučit neumíme.
No dobře, trochu ano, ale nemyslím že by v tom FP nějak významně pomohlo.

Je to podobne prastene, jako kdyz Java nema makra (rekneme a la Lisp), protoze by to bylo "moc slozite", ale pak se podobne problemy resi generovanim kodu, coz je samozrejme horsi.

To je skutečně praštěné, protože Java nemá makra "a la C" aby to nebylo moc složité. Ten rozdíl mezi C makry a LISP makry je naprosto zásadní.
Pokud vím, Java nemá LISP makra z daleko prostšího důvodu: nepatří do "mainstream" imperativního jazyka s celkem konzervativní koncepcí.

[balki]

Já bych prostě řekl že cílem může být odbourat zbytečnou byrokracii, ale ne byrokracii úplně (tak by tomu bylo v ideálním světě, kde programátoři vytvářejí a skládají matematické abstrakce).

Ja beru slovo byrokracie za pejorativni, takze samozrejme zbytecnou, nepejorativni vyraz by byl asi "proces".

Kazdopadne, to mi pripomina jednu z mych jinych vyhrad vuci navrhovym vzorum, ktera je, ze i konceptualne je to pomylena myslenka. V podstate se ocekava, ze programatori budou ten vzor sami rozeznavat (a pripadne aplikovat) v kodu. Ale to je hloupe, to co chces je naucit ten vzor pocitac (definovat urcitou abstrakci), aby to lide delat nemuseli, protoze lidska prace je draha a vede k chybam.

Je to podobne prastene, jako kdyz Java nema makra (rekneme a la Lisp), protoze by to bylo "moc slozite", ale pak se podobne problemy resi generovanim kodu, coz je samozrejme horsi.

Len mala poznamka, pocitace vedia rozoznavat navrhove vzory v kode, ale to je zbytocna vec.
Existuju na to pluginy pre eclipse.  Vzory su o humanizacii koderiny nie o vymyslani dalsieho matfyzackeho nastroja pre pocitace.

Pocitace nemaju rozum aby vedeli, ci kontext v ktorom vzory aplikuju je vhodny. Ani nevedia spravit patricne upravy, aby zachovali myslienku vzoru, ale prisposobili implementaciu podla situacie.

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.

[balki]

Pokud vím, Java nemá LISP makra z daleko prostšího důvodu: nepatří do "mainstream" imperativního jazyka s celkem konzervativní koncepcí.

Presne

[javaman ()]

A jak to teda je? Máme aplikaci, nic velkého, třeba sto tisíc řádků. Bude to jen backend, protože na front-end máme cool JS. Co je teda nejlepší použít, když to zlé OOP je k ničemu? Jakou architekturu? Proč se to dělá v tom nefunkčním OOP, když by to jinak šlo za třetinu času? Bude tam normální DB třeba. Nějaká ta logika, ale prostě nic složitého.

Nemám problém s novým přístupem, jen se trochu obávám, že většina obhájců neOPP a "pure" OPP nic moc neprogramuje. Nic proti tomu, jen abych měl představu.

[javaman ()]

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

[v]

třeba sto tisíc řádků

to je roztomilé )

[javaman ()]

Plus by mi Kit mohl vysvětlit, proč mu servisní třídy nepřijdou OOP.

Protože čím víc to tu čtu, tím méně vím, co vlastně dělám. Přijde mi, že ani OOP neumím Doufám, že se mě nikdo na pohovoru nebude ptát, co je OOP. Bych si vzpomněl na ty blogísky a tohle téma a byl bych ztracený.

[JS]

Tento argument naprosto nechápu.

Jeste jednou. Jde o to, ze dany vzor vysvetlime lidem, ale uz ne pocitacum. V pocitacovych jazycich takovy pristup nedava smysl.

Vezmi si abstrakce (vzory) ve funkcionalnim programovani, treba monadu. Kdyz pouziji v Haskellu monadu, jasne to pocitaci rikam, mam tam na to prislusnou abstrakci (v tomto pripade typovou tridu). A clovek, ktery to cte, nemusi badat, zda jsem pouzil monadu - proste to z toho kodu vidi. Mohl bych ten kod napsat i tak, ze by se pouzila monada (tedy by vypadal monadicky), ale pocitaci bych to nerekl (proste vyhnul se explicitnimu pouziti typove tridy Monad, a napsal bych si to co dela monada na kolene). Ale to by bylo mene citelne, a vice nachylne k chybam.

Ta druha situace nastava s GoF navrhovymi vzory. Neni to tak, ze by nesly formalne definovat (i kdyz vetsinou je vysledek trivialni) - viz ta prednaska o vzorech v Haskellu, kterou jsem postoval par prispevku zpet. Problem je v tom, ze si jejich zastanci odmitaji pripustit, ze nejenze to formalne definovat (a tedy abstrahovat v programovacim jazyce) lze, ale je to i vyhodnejsi (zlepsuje to citelnost kodu).

Pokud vím, Java nemá LISP makra z daleko prostšího důvodu: nepatří do "mainstream" imperativního jazyka s celkem konzervativní koncepcí.

To, ze nema makra, ovsem neznamena, ze nemusi resit problemy, kvuli kterym se makra pouzivaji, napriklad generovani kodu. To se pak v Jave resi zbytecne komplikovane (generovani v IDE, XML, atd.). Zase, jde o to, aby programatori nemuseli ad hoc resit problemy, na ktere by mohly v jazyce existovat vhodne abstrakce (nemusi to byt nutne makra).

Chapu, ze pro nekoho, kdo ty koncepty treba dobre nezna, to muze byt tezke prijmout, ze se daji veci delat lepe. Ja se take v minulosti dopoustel teto chyby.

[Mirek Prýmek]

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