Příspěvky

1696

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 13:37:47 »

Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.

To je zase zaměnění příčiny a následku.

Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.

Konstruktor slouží k tomu, aby se vytvořil objekt.

Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.

To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.

Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.

Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.

Nie pohodlnost, ale zdravy rozum. Vyplnit kilometrovy konstruktor, tam je trosku o hubu zistit poriadne, co kam ide.
Konstruktor sluzi predovsetkym na konfiguraciu objektu, to ze sa zhodou okolnosti pouziva aj na vytvorenie objeku je vedlajsia vec. Na vytvorenie objektu sa daju pouzit aj rozne factory metody/funkcie.

Jediny dovod konfigurovat vsetko v konstuktore je, ked je potrebny immutable objekt a vsetky fieldy su kvoli paranoji nastavene na filnal. (v jave)

Ja viem, ze som asi uchylny javista, ale bezny workflow je - Instancovat objekt, nakonfigurovat (nainjektovat), pustit init metodu objektu, ked je vsetko vo spravnom stave.  Ak to nerobi uz framework, tak to takto spravim rucne.

Menenie "stavu" objektu by sa nemalo robit cez setter (pokial sa tym mysli nieco viac nez konfiguracia). Ale prihodne nazvanou metodou typu changeKillingState(State.NOT_KILLING)

OK. Nesouhlasím. Zásadně. S ničím.

Můžem se přesunout dál.

1697

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 05:54:30 »

Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.

To je zase zaměnění příčiny a následku.

Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.

Konstruktor slouží k tomu, aby se vytvořil objekt.

Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.

To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.

Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.

Tak to je otázka filosofického rázu, zda do objektu injektovat fakta, tedy je vně objektu interpretovat a nebo mu předávat událostim či žádosti a jejich interpretaci nechat na něm. Myslím, že druhý způsob je vhodnější, protože neporušuje zapouzdření a vylepšuje flexibilitu systému omezením závislostí mezi objekty. Nestaráte se o to, co jak daný objekt dělá, ale o to, co po něm požadujete aby dělal.

Narážím na toto:

Kód: [Vybrat]

Person obj = factory.get() // někde seber nějaký objekt, ať nemáme konstruktor
obj.toString() // -> "Jmeno: NULL, Příjmení: NULL"

Pokud si rozumíme, tak rozhodně nesouhlasím, že by tam byl nějaký prostor k více možným přístupům. Vytvářet nemocné objekty (nedejbože z důvodu pohodlnosti) není dobrý způsob.

1698

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 03:51:32 »

Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.

To je zase zaměnění příčiny a následku.

Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.

Konstruktor slouží k tomu, aby se vytvořil objekt.

Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.

To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.

Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.

1699

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 00:52:04 »

No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.

To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.

Já bych věděl, ale nebude se ti to líbit.

Jedním z důvodů je v tom, že drtivá většina vývojářů OOP prostě neovládá. Navrhnout aplikaci objektově dobře není vůbec triviální.

Další důvod proč používat anemické objekty a servisní třídy je snaha o vyřešení problémů které OOP přináší. Někdy, někdy často, je kód v OOP děsně pitomej.

1700

Studium a uplatnění / Re:Jaký programovací jazyk zvolit?

« kdy: 29. 08. 2016, 19:23:21 »

Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...

Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.

No jo, jenže tobě nepřijde metrika pomocí peněz poněkud omezená? Blesk třeba zabaví spoustu lidí pokleslou zábavou. Ale z nikoho to lepšího člověka neudělá (tím bych definoval onu pokleslost). A ve výsledku s těmi lidmi musí spolupracovat i ti, kteří by rádi byli lepší.

S jazykem je to podobné. To, že je jazyk X značně rozšířený je dost blbé, pokud se v něm neprogramuje dobře. Protože to znamená, že v něm budu muset dříve či později programovat i já.

1701

Studium a uplatnění / Re:Jaký programovací jazyk zvolit?

« kdy: 26. 08. 2016, 23:32:47 »

return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.

Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

To hodně záleží na jazyku. Návratové kódy z minulého století často dokazují, že páni inženýři dříve to měli více vykoumané, než páni programátoři dneska.
Výjimky jsou nutnou cestou u jazyka, kde nelze zajistit odebrání si výsledku. V ostatních případech je to spíše komplikace.

A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.

To je dnes už zastaralá teorie jednoho návratového bodu.

Ale!? A to řekl kdo? A já měl naopak pocit, že tato zastaralá teorie zažívá comeback, páč jsme si ty slepé uličky prošli. To sou věci...

Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.

Já si přeci kůli tomu, abych se zbavil nějakých konstrukcí které se nějakému Kitovi nelíbí nebudu zasí**t kontrakt.

na začátku metody pomocí podmínek ošetřím vstupy a pak teprve provedu požadovanou akci.

Nejvíce úsměvné je to, že já to takhle dělám taky. Ale z úplně jiných důvodů. Tvá argumentace, že nechceš používat else je prostě střelená. Hledáš magii, kde žádná není.

1702

Studium a uplatnění / Re:Jaký programovací jazyk zvolit?

« kdy: 26. 08. 2016, 23:25:48 »

Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.

(1 + 2) is equals (2 + 1)

Tohle sice v Euklidovském prostoru platí, ale co to má společného s "else"?

To byla jen taková decentní narážka na to, že když poukážeš na blbost, kterou jsem neřekl, tak nezachráníš skutečnost, že si řekl blbost.

1703

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 24. 08. 2016, 19:45:50 »

Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.

Pokud se nepletu, tak nema ani pomerne zasadni vlastnosti, ktere tu jsou uz desitky let. Namatkou treba algebraicke typy + pattern matching (vcetne Maybe/Option typu), generika, makra... Nehlede na to, ze "posledni vykriky" IT mody nemusi nutne znamenat, ze jde o samoucelne vystrelky. Kdyz Go srovnam s "modernimi" jazyky jako Rust a Julia a asi i Nim, prijde mi, ze ta jeho konzervativnost je dana spise omezenosti jeho autoru, kteri se zasekli nekde v 70. letech a svoji omezenost ted vydavaji za prednost.

Tak todle je fakt opravdu mimo ... pošli stejnou stížnost Jave/C++/C#/... starej jazyk se prostě vyvíjí pomalu a JS je starej jazyk (21 let).

Nehedě na to že v ES6 už něco jak náznaky pattern matchingu jsou.

Nepřehlédl jsi se, že reakce je na jazyk GO, a nikoliv na Javascript?

1704

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 24. 08. 2016, 14:57:36 »

To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování ...

Co s tím má společné statické typování?

Hodně, protože zamezí zbytečným stupidním chybám za běhu.

Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.

To je ale hodně mimo téma. Diskuse byla o doesNotUnderstand, které mají i některé statické jazyky (Java) a závěr byl, že statické typování je rozumné používat všude, kde to je možné. V případě nutnosti se pak sáhne k zachycení volání a přesměrování, v C# pomocí dynamic, od čehož se tato diskuse rozvinula.

Tak si možná jen nerozumíme.

doesNotUnderstand je důležitá až zásadní vlastnost OOP. Statické typování OOP nepotřebuje (i když v praxi je to mnohem důležitější pattern). A vzhledem k subjektu vlákna...

1705

Studium a uplatnění / Re:Jaký programovací jazyk zvolit?

« kdy: 24. 08. 2016, 14:08:51 »

Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.

(1 + 2) is equals (2 + 1)

1706

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 24. 08. 2016, 14:01:41 »

To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování ...

Co s tím má společné statické typování?

Hodně, protože zamezí zbytečným stupidním chybám za běhu.

Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.

1707

Studium a uplatnění / Re:Jaký programovací jazyk zvolit?

« kdy: 24. 08. 2016, 01:16:22 »

V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.

Takže jestli to chápu dobře, tak tím, že vyhodím else a nahradím ho extra metodou docílím toho, že metoda bude dělat jen jednu věc a pořádně? To jako vážně?

Tvé zkratky jsou fantastické. Jsem docela rád, že už nejsem začátečník a nemusím se od tebe učit.

1708

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 18. 08. 2016, 12:21:34 »

Kdybych měl euro za každé takové sebejisté prohlášení, tak jsem Elon Musc.

Chtel bys to snad poprit? Nestojim o to srat se s instalovanim a rozchozenim Qt, kdyz muzu pouzit lepsi nastroj a primo pro to urceny. Samozrejme, kdyz delam pro windows.

Tak to je zásadní rozdíl že jo. A ještě zásadnější je v tom, že nepracuješ v mém týmu. Když by ano, tak bych očekával určitou kvalitu výsledku. Na čem to vytvoříš by mě nezajímalo. A tvé názory by museli být zhodnotitelné. Nestačí jen něco plácnout. Musíš si za tím stát. Svou výplatou samozřejmě.

1709

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 18. 08. 2016, 12:14:27 »

Tak já ti mohu jen popřát, ať ti to nadšení vydrží. Ostatně proč ne.

Jo, takze na linuxu, kterej jsem vyzkousel, by bylo me nadseni obrovsky a nechtel bych nic jinyho. Proc bych se mal jako zajimat o platformu, ktera je beztak mrtva a nabidky na linux jsou beztak jenom sami administratori?

To chápeš špatně. Mě je celkem jedno co tě baví. A tvé názory si sice vyslechnu, ale to je tak zatím asi všechno.

1710

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 18. 08. 2016, 02:04:34 »

tak ti muzu rict, ze lepsi appku ve spojeni C#+WPF pro windows neudelas. muzes psat kolik chces, ze Qt je multiplatformni a podobne kravoviny, jednoducho je to neprustrelnej fakt.

Kdybych měl euro za každé takové sebejisté prohlášení, tak jsem Elon Musc.

A je jen otazka casu, kdyz i .NET se rozsiri na linux a dal. uz ted vysel .NET Core 1.0.

Řekl bych že Foundation byl větší kalibr, a nechytlo se to. Takže nás nevystrašíš.

Sam jsem pouzival linux na skole. System dobrej pro servry, nebo pro takove to obycejni vyuziti PC. Jenomze jako OS, kde mam neco vyvijet, no hruza.

Tak já ti mohu jen popřát, ať ti to nadšení vydrží. Ostatně proč ne.