Příspěvky

1381

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 10. 09. 2015, 23:52:25 »

Projed si historii diskuse. Problem nastane, kdyz mas mutable objekty.

To je vše o tom, že si někdo myslí, že čtverec je obdélník. Když pak zjistí, že některé vlastnosti na to nepasují, zavrhne dědění jako celek - s vaničkou vyleje i dítě. Přitom kdyby neudělal chybu v počátečním předpokladu, že čtverec == obdélník, tak by věděl, že tyto dvě třídy od sebe dědit nemohou.

Nebo dědit mohou, ale musí být na to objektový systém připraven, příkladem být může CLOS.

Nemohou, protože čtverec není obdélník a kružnice není elipsa. Jsou to sourozenci mající společné rodiče.

Proč tady musí být zatvrzelí odpůrci versus zatvrzelí zastánci dědičnosti? Je tak těžké pochopit, že někdy se dědičnost hodí a jindy ne? Že by sourozenecké třídy neměly mezi sebou dědit?

To je megahovadina, čtverec je z definice obdélník.

1382

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 10. 09. 2015, 18:55:49 »

Zrovna Go to má takhle: "Dědí" se jenom interface, nejsou virtuální metody a předek tak nemůže zavolat metodu z potomka. Pomůže to k něčemu ?

Nedědí se nic. Předek nemůže volat metodu potomka, protože žádný předek a potomek neexistuje. Pomůže to k tomu, že se nebudou vést nekonečné debaty, jestli je čtverec potomek obdélníka nebo obdélník předem čtverce.

Když se vezme čtverec, obdélník, kosočtverec a rovnoběžník, tak dědičnost vytvoří "diamant". Nicméně i tak se dá třeba výpočet plochy napsat jen jednou.

1383

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 10. 09. 2015, 16:55:08 »

Nicméně já bych se vrátil k původnímu dotazu a podpořil bych Kit-a: stude, koukni se na jazyky, kde se na dědičnost nehraje a místo toho se používají volně kombinovatelné protokoly. Největší šanci na mainstreamovost má asi Go.

Různé implementace podobného principu:

Go: https://tour.golang.org/methods/5
Elixir: http://elixir-lang.org/getting-started/protocols.html
Haskell: https://www.haskell.org/tutorial/classes.html
Rust: https://doc.rust-lang.org/book/traits.html

...a Swift

1384

Studium a uplatnění / Re:Co má v IT nejlepší budoucnost?

« kdy: 10. 09. 2015, 14:22:28 »

OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie.

Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.

To je možná spíše jen hlavní způsob využití OOP většinou programátorů.

1385

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 10. 09. 2015, 14:19:53 »

Neni to nutna podminka. Muzes mit trebas OOP postavene na prototypech (nejsem fanda, ale reseni to je).

Prototypy umožňují dědičnost z principu, byť je k dědění nutná rozsáhlá ruční práce.
Jazyk kde dědičnost opravdu není je hypotetická Java bez keyword extends.

Samotné implements je taky dědičnost, byť trochu jiná.

1386

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 10. 09. 2015, 02:17:25 »

JOOQ jen generuje kód. "Magie" to je jen pro někoho, kdo neví, jak to funguje. Taky by to mělo být efektivnější.

Neříkám, že NQ je špatné, naopak, je to dost zajímavá věc… Ale jistou magičnost tomu upřít nelze – v zásadě jde o funkci, která převádí výraz v jednom jazyce na výraz v jiném jazyce (třeba Java → SQL nebo Java → JPQL) a problém je v tom, že definiční obor té funkce je velmi široký (formálně) a obor hodnot je oproti tomu hodně omezený a tak úplně to na sebe nepasuje. Jen malá podmnožina hodnot definičního oboru dává smysl a je rozumně převoditelná na výstup.

Na jednu stranu tedy NQ pomáhá (píšu v Javě, kompilátor mi kontroluje výrazy), ale na druhou stranu škodí – zvyšuje nejistotu (ne vše, co jde zkompilovat, je OK), zatemňuje, přidává další úroveň abstrakce/nepřímosti a klade vyšší nároky na programátora.

Rozhodně nechci NQ zavrhovat, ale přijde mi hloupé odsuzovat nástroje typu JOOQ a považovat je za něco nedostatečného – když právě tyhle nástroje můžou být lepší volbou.

Vyšší nároky nikde nevidím, spíš naopak. NQ nepřidává žádnou úroveň, naopak ubírá.

1387

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 09. 09. 2015, 18:34:03 »

@zboj
urcite nie
behavior fail

Určitě jo. V tomto případě to ani není težké na pochopení.

Projed si historii diskuse. Problem nastane, kdyz mas mutable objekty.

To ale platí obecně, nesouvisí to se čtvercema a obdélníkama.

1388

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 09. 09. 2015, 18:12:30 »

@zboj
urcite nie
behavior fail

Určitě jo. V tomto případě to ani není težké na pochopení.

1389

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 09. 09. 2015, 18:11:19 »

To je dost nesmysl, bo code reuse.

Prakticky každá firma (co jsem viděl), která měla zoufale neudržitelný kód ho měla zoufalí proto, že dědily kůli code reuse. Takže za mě fakt ne!

To je lidma, ne děděním.

1390

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 09. 09. 2015, 14:21:24 »

stvorec extends obdlznik je standardny fail lebo liskov substitutuion principle

Tak v tomto případě LSP perfektně funguje, máš v tom zmatek.

1391

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 09. 09. 2015, 14:18:07 »

Řekněme, že chci mít objekty čtverec, obdélník, kosočtverec a rovnoběžník. Je jasné, že s jednoduchou dědičností se daleko nedostanu. Proto obecný dotaz: existuje nějaké jiné paradigma, ve kterém lze vztahy mezi objekty vyjádřit lépe? Pokud ano, na jaký jazyk bych se měl podívat?

Preco chces vlastne dedit? Nestacia ti 4 structury bez dedicnosti?

To je dost nesmysl, bo code reuse. Jasně, šlo by to přes rozšíření (třeba výpočet obsahu), ale to je mimo původní otázku.

1392

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 09. 09. 2015, 14:15:40 »

Koukni taky na http://www.jooq.org/ – umožňuje psát typově bezpečné dotazy. Je to někde na půli cesty mezi psaním čistého SQL a ORM.

Pleteš si (stejně jako perceptron) NQ a SODA.

Píšu, ať se na to podívá, ne že je to NQ. Ono někdy poslouží líp nástroj typu JOOQ, než tam přidávat ještě další úroveň abstrakce (a svým způsobem magie) a posouvat se ještě dál od nativního jazyka, se kterým pracuje databáze. V extrémních případech je i ručně psané SQL příliš vysokoúrovňové a optimalizátor v databázi nesestaví plán tak, jak bys potřeboval.

JOOQ jen generuje kód. "Magie" to je jen pro někoho, kdo neví, jak to funguje. Taky by to mělo být efektivnější.

1393

Studium a uplatnění / Re:Má cenu studovat IT navazující?

« kdy: 09. 09. 2015, 14:06:36 »

Teď už čekám jen na diskuzi o Chomského politických názorech.

Spíš by byla zajímavá diskuse o tom, jestli je Chomsky humanitní pakáž.

Asi ne, vždyť psal matematické články a jeho přístup k jazykovědě je taky matematický (resp. algebraický).

1394

Studium a uplatnění / Re:Co má v IT nejlepší budoucnost?

« kdy: 09. 09. 2015, 14:04:16 »

Spíše než FP bych řekl obecněji "post-OOP", protože OOP nezmizí, jen se trochu modifikuje, viz dnes Swift.

No rikaji tomu "multi-paradigm"

To jsem nemyslel. Nejde o mix, ale koherentní paradigma.

1395

Studium a uplatnění / Re:Co má v IT nejlepší budoucnost?

« kdy: 09. 09. 2015, 13:33:16 »

Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.

Třeba takový Haskell vznikl v roce 1990, Lisp dokonce už v 1958... a pořád nic.

Ako pise Nekonala, vsetko ma svoj spravny cas. Dnes OOP naraza na svoje hranice, za ktore ist uz nevie. Nepomahaju ani navrhove vzory. Hovorim o velkych OOP molochoch, cca milion riadkov zdrojakov a viac. O uz ide iba patch na patch, workaround na workaround..

Odporucam nepremyslat nad konkretnymi jazykmi ale zacat premyslat nad platformami. Haskell a Lisp asi uz masovka nebudu nikdy ale uplne sa staci podivat na taky .NET

Vyhravaju platformy.. Iba python, perl, groovy mali stastie, ze sa presadili ako samostatne jazyky s uspesnou portaciou mimo unix..

Mimochodom, dostal som nedavno ponuku programovat funkcionale za nastupny plat prevysujuci seniora v Jave v Prahe. Je malo firiem, na ktore na to prichadzaju ale predpokladam, ze ich pocet bude casom rast.. Len sa musi vystriedat este jedna generacia programatorov. Dnesni typicky programator sa funkcionalnemu programovaniu brani vsetkymi pismenkami jeho klavesnice..

Spíše než FP bych řekl obecněji "post-OOP", protože OOP nezmizí, jen se trochu modifikuje, viz dnes Swift.