Co si myslíte o OOP?

Re:Co si myslíte o OOP?
« Odpověď #255 kdy: 31. 12. 2018, 11:30:55 »
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?

2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Tohle mi prijde zvlastni. refactoring chapu jako "cisteni" kodu v pripade, ze uz funguje spravne tzn. beze zmeny funkcionality... Abych mohl delat refactoring "bezpecne" potrebuju mit uz v ruce nejaky kontrolni mechanizmus (testy nebo typovou kontrolu), abych mohl po vycisteni prokazat, zachovani funcionality.

Takze, kdyz budu delat nejaky proof of concept tak muzu bez testu a bez typu, ale rozhodne to pak nebudu refactorovat do nejake produkcni verze, protoze bych se osypal.



Re:Co si myslíte o OOP?
« Odpověď #256 kdy: 31. 12. 2018, 11:35:23 »
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?
S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.

Inkvizitor

Re:Co si myslíte o OOP?
« Odpověď #257 kdy: 31. 12. 2018, 11:47:30 »
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)

Co máš na mysli těmi nadtypy, prosímtě?

Re:Co si myslíte o OOP?
« Odpověď #258 kdy: 31. 12. 2018, 11:56:49 »
Co máš na mysli těmi nadtypy, prosímtě?
Typ je množina hodnot. Nadtyp je nadmnožina.

Inkvizitor

Re:Co si myslíte o OOP?
« Odpověď #259 kdy: 31. 12. 2018, 12:02:20 »
Co máš na mysli těmi nadtypy, prosímtě?
Typ je množina hodnot. Nadtyp je nadmnožina.

Tomu rozumím, ale asi tušíš, že na to jsem se neptal. Jde mi o tu implementaci; chápu, že třeba v Javě máš Object, narážíš konkrétně na Go, ale pokud tomu dobře rozumím, tak nízkoúrovňové jazyky obecně nic takového nemají.


Re:Co si myslíte o OOP?
« Odpověď #260 kdy: 31. 12. 2018, 12:08:07 »
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?
S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.

To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)

Re:Co si myslíte o OOP?
« Odpověď #261 kdy: 31. 12. 2018, 12:10:22 »
Tomu rozumím, ale asi tušíš, že na to jsem se neptal.
Netušil jsem, jinak bych ti tak neodpovídal :)

Jde mi o tu implementaci; chápu, že třeba v Javě máš Object, narážíš konkrétně na Go, ale pokud tomu dobře rozumím, tak nízkoúrovňové jazyky obecně nic takového nemají.
Nevím, co jsou "nízkoúrovňové jazyky". Bavíme se obecně o různých jazycích, takže těžko mluvit o konkrétní implementaci. Prakticky těch mechanismů může být víc, ale všechny mají stejný "filosofický" princip:

1. typ je "sjednocením" dvou typů -> algebraické typy (tj. prakticky: chci mít možnost napsat funkci, která vrací string nebo int)

2. nadtyp je definovaný tím, že má jenom některé vlastnosti podtypu -> dědičnost, interfejsy

V jazyce OOP klíčová slova "předek" a "Liskovové substituce".

Re:Co si myslíte o OOP?
« Odpověď #262 kdy: 31. 12. 2018, 12:12:04 »
To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
No jistě, ale to je něco jinýho.

Hot reloading v Erlangu je o tom, že ti běží na serveru nějaká aplikace a ty v ní za běhu změníš část kódu. Klíčový je to, že měníš existující aplikaci, zatímco v REPLu vlastně vytváříš novou.

Inkvizitor

Re:Co si myslíte o OOP?
« Odpověď #263 kdy: 31. 12. 2018, 12:20:25 »
1. typ je "sjednocením" dvou typů -> algebraické typy (tj. prakticky: chci mít možnost napsat funkci, která vrací string nebo int)

Tedy "sum type"? Tak tam má Go asi fakt handicap.

2. nadtyp je definovaný tím, že má jenom některé vlastnosti podtypu -> dědičnost, interfejsy

No ale interface naopak podporuje...

Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.

Re:Co si myslíte o OOP?
« Odpověď #264 kdy: 31. 12. 2018, 12:24:15 »
Tedy "sum type"? Tak tam má Go asi fakt handicap.
Jo. Nebo se používá i termín "composite type".

No ale interface naopak podporuje...
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.

JS

Re:Co si myslíte o OOP?
« Odpověď #265 kdy: 31. 12. 2018, 12:31:35 »
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.

Me by zajimala ta lepsi alternativa sve doby ke vsemu z toho, co jsi uvedl.

Unix, OS/2, WordPerfect, Quattro Pro, Perl, Netscape, Delphi, jakykoli jiny sablonovaci system, Guile, Visual Studio, horizontalni skalovani aplikace na miru (Google pozdeji od MapReduce uplne ustoupil), temer jakakoli SQL databaze.

Nekdy tech alternativ bylo i vic, pisu ty hlavni. Ale nebyly tolik v mode.

BaldSlattery

Re:Co si myslíte o OOP?
« Odpověď #266 kdy: 31. 12. 2018, 12:34:57 »
Upřesnění:

máš k dispozici algebraické typy
Tohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".
Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.

Re:Co si myslíte o OOP?
« Odpověď #267 kdy: 31. 12. 2018, 12:37:01 »
Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.
No je to oboje. Chceš dosáhnout stejného cíle (vytvoření "obecnějšího typu") a jdeš na to buď přes algebraické typy nebo přes dědičnost nebo přes interfejsy.

Kiwi

Re:Co si myslíte o OOP?
« Odpověď #268 kdy: 31. 12. 2018, 12:38:21 »
Když by to bylo tak skvělé, tak proč se to nedělá?
Svět by byl dnes jistě úplně jiný, pokud by se v něm prosazovaly zásadně jen věci, které jsou skvělé.

Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)

Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Konkrétní příklad bych vzal mnohem prostší - chceš realizovat jakýsi print(x), který zajistí vypsání argumentu na terminál. Jaký datový typ x-u by ta funkce měla podle tebe optimálně očekávat a proč? V čem mi jakožto vývojáři pomůže, že ta funkce očekává ten konkrétní datový typ? Uvažuješ-li o stringu, tak pokračuj v úvaze dál - jak se teda pak vypořádat s ne-stringy. Nebo třeba seznam v Pascalu...

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?
To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.

Taška na rohlíky je provokace. Jestli nechceš vést vážou diskusi, tak to řekni rovnou :-)

Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.

Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.

A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)
Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů. Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci. Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli. Vidím to tak, že ve statickém případě bych si musel definovat nějaký typ "zboží", který pojme veškerý sortiment plánovaného nákupu. Jenže proč bych se musel omezovat na cokoli, co třeba je menší než ten Boeing, když ze zadání problému neplyne, že bych nikdy neměl chtít koupit Boeing?

Statické typování mě nutí, abych dopředu znal nějaké omezení, nebo abych si ho uměle vytvořil, ačkoli z řešeného problému vůbec neplyne. To první je často nemožné a tedy vede k tomu druhému, což je smrtící. Nejčastějším problémem, se kterým se vývojář ve své pracovní době potýká, není obvykle přímo problém, který má za úkol vyřešit, ale jak se vypořádat s problémy, které si nadělal sám sobě dříve nebo které mu vymysleli jeho předchůdci. Takže jakmile se zákazník zeptá, proč nejde koupit Boeing, co mu na to odpovíš? A jak se budeš tvářit, až po X mandays práce, spočívající v překopávání půlky programu kvůli Boeingu, ti zákazník nezaplatí ani halíř, protože v té původní smlouvě o dílo není nikde napsáno, že by ten program neměl umět nakupovat Boeingy?

BaldSlattery

Re:Co si myslíte o OOP?
« Odpověď #269 kdy: 31. 12. 2018, 12:39:05 »
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Go má rozhraní (kterému výše říkáš “nadtyp”), což je právě ten hledaný duck typing. Viz též vnitřní implementace rozhraní v Go, dost to připomíná dynamické “typování” à la Smalltalk (navenek to je bohužel omezené syntaxí, ale jde to obejít).