Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: VencaP 01. 08. 2016, 07:46:43
-
Existuje nějaké vývojové prostředí, kde bych mohl ve webovém prohlížeči programovat v Javě a taky to debuguvat?
-
Existuje nějaké vývojové prostředí, kde bych mohl ve webovém prohlížeči programovat v Javě a taky to debuguvat?
Existuje - Eclipse CHE viz zde https://www.eclipse.org/che/
Nejejdnodušeji ho vyzkoušíte když si nainstalujete virtualbox, vagrant a pak si stáhnete vagrantFile pro EclipseCHE
-
Existuje - Eclipse CHE viz zde https://www.eclipse.org/che/
Nejejdnodušeji ho vyzkoušíte když si nainstalujete virtualbox, vagrant a pak si stáhnete vagrantFile pro EclipseCHE
Proč potřebuji virtualbox, když to má běžet v prohlížeči ? Protože bez lokální instalace je to výkonově nepoužitelné ?
-
Protoze je to "cloudovy" IDE. Tzn musi to bezet nekde na serveru a na strankach projektu je ke stazeni image.
Staci se podivat na jejich stranky...
-
Pripadne existuje https://codenvy.com/ , ktery stavi primo na Eclipse Che
-
Existuje - Eclipse CHE viz zde https://www.eclipse.org/che/
Nejejdnodušeji ho vyzkoušíte když si nainstalujete virtualbox, vagrant a pak si stáhnete vagrantFile pro EclipseCHE
Proč potřebuji virtualbox, když to má běžet v prohlížeči ? Protože bez lokální instalace je to výkonově nepoužitelné ?
1. Vagrant a VirtualBox vám umožní mít specifické prostředí pro každý projekt, nezasviníte si lokální instalaci, na vyzkoušení ideální.
2. jak je v příspěvku výše, dá se stáhnout image
3. To nejdůležitější, běží to i na codenvy.com jako cloud. Stačí si tam založit bezplatný účet, a můžete ihned pracovat. Založení účtu zde https://www.eclipse.org/che/getting-started/cloud/
-
On hledá něco na vývoj a vy mu nabízíte Eclipse :D Ani Eclipse v cloudu zázračně nezačne fungovat. Eclipse bylo vždy pro lopaty.
-
Protoze je to "cloudovy" IDE. Tzn musi to bezet nekde na serveru a na strankach projektu je ke stazeni image.
Staci se podivat na jejich stranky...
Na stránky jsem se podíval. Ten image jsem asi přehlédl, ale je tam možnost vytvořit si workspace i s virtuálním Linuxem přímo na jejich serveru.
-
On hledá něco na vývoj a vy mu nabízíte Eclipse :D Ani Eclipse v cloudu zázračně nezačne fungovat. Eclipse bylo vždy pro lopaty.
To jsme rádi, že jsi nám to hezky vysvětlil a objasnil.
A nějaké další moudra při práci s krumpáčem, míchačkou případně se srpem by na skladu nebyla?
-
Co to povídáš? Prostě pokud někdo programuje v Eclipse, tak toho asi moc nezvládne. Taková běžná lopata, no. Nejhorší ze všech použitelných prostředí.
-
Co to povídáš? Prostě pokud někdo programuje v Eclipse, tak toho asi moc nezvládne. Taková běžná lopata, no. Nejhorší ze všech použitelných prostředí.
tzv. argumentum ad lopatam
-
Nechceš mi doufám říct, že někdo dobrý bude používat Eclipse? Ten nefunkční shit, který má pořád poblémy? Opravdu?
-
Nechceš mi doufám říct, že někdo dobrý bude používat Eclipse? Ten nefunkční shit, který má pořád poblémy? Opravdu?
Moje volba to neni. Ale to nebylo o tom, co je lepsi IDE (IntellijJ, samozrejme), ale o tom, jak argumentujes.
-
Tak to je na fórech základ. Je vtipný, že většina lidí na to reaguje jako na normální argumenty. Vlastně v reálu taky :D
-
Co to povídáš? Prostě pokud někdo programuje v Eclipse, tak toho asi moc nezvládne. Taková běžná lopata, no. Nejhorší ze všech použitelných prostředí.
Jasně, Vim je pro vývoj v Javě přímo ideální. Nechápu, jak někdo může používat nějaká IDE.
-
Jako fórek dobrý, ale oba víme, že je to u tebe smutná pravda :D
-
Jako fórek dobrý, ale oba víme, že je to u tebe smutná pravda :D
U mne je to veselá pravda, protože s Vimem vesele vyvíjím nejen lokálně, ale i na cloudu. Nepotřebuji ani ten browser, stačí mi obyčejný terminál, který ani nemusí být grafický.
-
Vesele asi určitě, ale ten vývoj bych v tom neviděl :D Refactoring teda děláš nějakým cool skriptem, který vůbec nerozumí projektu, takže udělá půlku věcí blbě?
-
Při refactoringu přece pracuji pouze s jedním souborem. Nepleť si refactoring s redesignem.
-
Co to povídáš? Prostě pokud někdo programuje v Eclipse, tak toho asi moc nezvládne. Taková běžná lopata, no. Nejhorší ze všech použitelných prostředí.
Vida, takze se u pohovoru muzu ptat, co clovek pouziva za prostredi a pekne si to vyfiltrovat. Jak maji nekteri ten svet jednoduchej... :)
-
Při refactoringu přece pracuji pouze s jedním souborem. Nepleť si refactoring s redesignem.
Tak to máš zajímavou definici :D Škoda, že ostatní by ti nerozuměli. A to nejen s tím Vimem. Jak můžeš pracovat s jedním souborem? Jo ták, ten tvůj skript totiž ostatní nevidí, tak to změní jen v jednom. OK :D
Co to povídáš? Prostě pokud někdo programuje v Eclipse, tak toho asi moc nezvládne. Taková běžná lopata, no. Nejhorší ze všech použitelných prostředí.
Vida, takze se u pohovoru muzu ptat, co clovek pouziva za prostredi a pekne si to vyfiltrovat. Jak maji nekteri ten svet jednoduchej... :)
Přesně tak to je. Kdo používá Eclipse, je jasná lopata a víc jak 60 jí nedávej.
-
Při refactoringu přece pracuji pouze s jedním souborem. Nepleť si refactoring s redesignem.
Tak to máš zajímavou definici :D Škoda, že ostatní by ti nerozuměli. A to nejen s tím Vimem. Jak můžeš pracovat s jedním souborem? Jo ták, ten tvůj skript totiž ostatní nevidí, tak to změní jen v jednom. OK :D
Refactoring nijak neovlivňuje rozhraní třídy. Ostatním do toho nic není, když v ní dělám refactoring. Nemá to na ně žádný vliv.
-
Ahaaa, tak to jo. Co ještě sis sám vymyslel a teď používáš? :D
-
Při refactoringu přece pracuji pouze s jedním souborem. Nepleť si refactoring s redesignem.
Bullshit.
Cela skupina "refactoring to patterns" neni zdaleka lokalni.
Nemuzes si predstavovat, ze kazdy refactoring je ten zakladni "extract method" nebo "extract variable", co se s nim pracne patlas ve vimku.
-
Neboj, Vim umí efektivně pracovat s více soubory otevřenými současně.
-
Hlavně tam nahrávejte nějaký suprdupr tajný projekty ať provozovatel serveru ví, na čem makáte.
-
Hlavně tam nahrávejte nějaký suprdupr tajný projekty ať provozovatel serveru ví, na čem makáte.
Hlavně si svůj privátní server nenechej hacknout nebo ukrást.
-
Doporučil bych Emacs přes SSH.
-
Vesele asi určitě, ale ten vývoj bych v tom neviděl :D Refactoring teda děláš nějakým cool skriptem, který vůbec nerozumí projektu, takže udělá půlku věcí blbě?
Na pomalém připojení je to určitě veselejší než používat nějaké sračkové IDE, které musí stahovat celé soubory.
Od kdy refaktoring souvisí s IDE? Existují tooly jako https://github.com/python-rope/rope. Pro Javu určitě existuje něco podobného.
-
Vesele asi určitě, ale ten vývoj bych v tom neviděl :D Refactoring teda děláš nějakým cool skriptem, který vůbec nerozumí projektu, takže udělá půlku věcí blbě?
Na pomalém připojení je to určitě veselejší než používat nějaké sračkové IDE, které musí stahovat celé soubory.
Od kdy refaktoring souvisí s IDE? Existují tooly jako https://github.com/python-rope/rope. Pro Javu určitě existuje něco podobného.
Zřejmě si javaman pod pojmem refaktorování představuje změny názvů tříd, objektů a metod napříč celým projektem. Musíme pochopit, že na takovou trivialitu potřebuje IDE, protože bez něj to nezvládne.
-
Vesele asi určitě, ale ten vývoj bych v tom neviděl :D Refactoring teda děláš nějakým cool skriptem, který vůbec nerozumí projektu, takže udělá půlku věcí blbě?
Na pomalém připojení je to určitě veselejší než používat nějaké sračkové IDE, které musí stahovat celé soubory.
Od kdy refaktoring souvisí s IDE? Existují tooly jako https://github.com/python-rope/rope. Pro Javu určitě existuje něco podobného.
Jak souvisí připojení s vývojem? Ty máš snad soubory někde na síti? WTF?
Jestli to dokážeš bez IDE, tak jsi borec. Co si tak pamatuju, tak ani IDE to třeba u patlanin typu PHP, Python neumí. Ale tvoje skriptíky to určitě dají bez problémů :D
Vesele asi určitě, ale ten vývoj bych v tom neviděl :D Refactoring teda děláš nějakým cool skriptem, který vůbec nerozumí projektu, takže udělá půlku věcí blbě?
Na pomalém připojení je to určitě veselejší než používat nějaké sračkové IDE, které musí stahovat celé soubory.
Od kdy refaktoring souvisí s IDE? Existují tooly jako https://github.com/python-rope/rope. Pro Javu určitě existuje něco podobného.
Zřejmě si javaman pod pojmem refaktorování představuje změny názvů tříd, objektů a metod napříč celým projektem. Musíme pochopit, že na takovou trivialitu potřebuje IDE, protože bez něj to nezvládne.
To ty radši ručně edituješ 270 souborů a ještě ti jich 250 uteče. OK, ne každý má tolik času a chuti :D
-
Na pomalém připojení je to určitě veselejší než používat nějaké sračkové IDE, které musí stahovat celé soubory.
Jak souvisí připojení s vývojem? Ty máš snad soubory někde na síti? WTF?
Osobně vyvíjím na svém serveru v lokální síti, ale na cloudu je to přece jen praktičtější.
Jestli to dokážeš bez IDE, tak jsi borec. Co si tak pamatuju, tak ani IDE to třeba u patlanin typu PHP, Python neumí. Ale tvoje skriptíky to určitě dají bez problémů :D
Jistě, ty skriptíky to dají bez problémů.
Zřejmě si javaman pod pojmem refaktorování představuje změny názvů tříd, objektů a metod napříč celým projektem. Musíme pochopit, že na takovou trivialitu potřebuje IDE, protože bez něj to nezvládne.
To ty radši ručně edituješ 270 souborů a ještě ti jich 250 uteče. OK, ne každý má tolik času a chuti :D
Klidně i 2000 souborů. Vimu je to jedno a neuteče mu nic. Takhle jsem kdysi dodělával povinné komentáře, které kdosi vyžadoval. V každém souboru byl samozřejmě jiný v závislosti na kódu. Stačilo jen Vimu vysvětlit, ze kterých údajů to má poskládat a udělal to ve všech souborech jedním vrzem.
Ještě mi uniká, proč se snažíš přejmenovávat objekty a metody v celém projektu naráz. To máš rozházené závislosti všude možně? Vyzná se v těch tvých projektech i někdo jiný?
-
Vývoj na serveru :D OK, ještě mi chybí, že to máte na sdíleném disku a verzování děláte adresáři.
To je zajímavý, jak to asi poznají, když to technicky u těch jazyků nejde. Prostě luxusní skriptíky...
Špatně se mu vysvětluje, že něco dostane až za chodu, tak jestli by mohl chvíli počkat, ne?
Jak všude možně? Prostě závislosti se někde používají.
-
Vývoj na serveru :D OK, ještě mi chybí, že to máte na sdíleném disku a verzování děláte adresáři.
To je zajímavý, jak to asi poznají, když to technicky u těch jazyků nejde. Prostě luxusní skriptíky...
Špatně se mu vysvětluje, že něco dostane až za chodu, tak jestli by mohl chvíli počkat, ne?
Jak všude možně? Prostě závislosti se někde používají.
Pro verzování je dnes už standardem Git. Znáš ho? Je to skvělý systém.
Vyvíjet na sdíleném disku mě nenapadlo. Zřejmě s tím máš bohaté zkušenosti.
Kupodivu Vim dokáže využít nejen informace, které jsou v souboru, ale i metainformace. Udělat modifikační šablonu je pak hračka a vlk se nažere.
Závislostí mezi třídami mám minimum. Objekty ani metody zpravidla nemám důvod přejmenovávat, protože mám pro ně osvědčenou sadu slov, pro které už není mnoho důvodů ke změně. Stačí pochopit rozdíly mezi search() nebo seek() apod. Takové názvy metod už není nutné měnit a v projektu jsou už natrvalo.
-
Jak souvisí připojení s vývojem? Ty máš snad soubory někde na síti? WTF?
Tématem diskuze je online IDE. Předpokládám, že má sloužit k editaci souborů někde na síti. Emacs přes SSH je online IDE.
Jestli to dokážeš bez IDE, tak jsi borec. Co si tak pamatuju, tak ani IDE to třeba u patlanin typu PHP, Python neumí. Ale tvoje skriptíky to určitě dají bez problémů :D
Používám k tomu Emacs. To je IDE. Ale stačil by i sed. Důležité je mít kód pokrytý testy. IDE to nedokáže na 100% ani v Javě.
-
Neboj, Vim umí efektivně pracovat s více soubory otevřenými současně.
Nerikam, ze ne. Rikam, ze tvoje "refaktoring nemeni rozhrani tridy" ne nesmysl.
-
Vzdy som si myslel, ze dolezite je co clovek vyprodukuje a za aky cas a nie ake IDE pouzije. Vy dvaja ste tazke pripady.
-
Vzdy som si myslel, ze dolezite je co clovek vyprodukuje a za aky cas a nie ake IDE pouzije. Vy dvaja ste tazke pripady.
Nevím koho myslíš těmi těžkými případy, ale souhlasím s tebou. Doporučuji používat nástroje, které nejsou vázány na konkrétní editor nebo IDE.
-
Vzdy som si myslel, ze dolezite je co clovek vyprodukuje a za aky cas a nie ake IDE pouzije. Vy dvaja ste tazke pripady.
Nevím koho myslíš těmi těžkými případy, ale souhlasím s tebou. Doporučuji používat nástroje, které nejsou vázány na konkrétní editor nebo IDE.
Tak v IDE mám i okénko terminálu, takže mohu využívat i jiné nástroje, než ty, které nabízí IDE.
Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity. Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit. Taky vás nasměrují určitým směrem, investujete do nich hodně práce, takže ten směr změnit bude pro vás složité, časem se stane neoptimální, ale na jeho změnu díky předešlým investicím, nikdy nepřistoupíte. Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty. Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.
Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.
Ono se to nezdá, ale systém pro vytváření aplikací je v 98% de facto mnohem složitější systém, než výsledná aplikace a to bez ohledu na základ, který k němu použijete.
-
Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.
Uživatelé Vimu a Emacsu s klidným svědomím zahodili specializovaná IDE hned na začátku a používají nástroj, který jim nejlépe vyhovuje nejen pro aktuální práci.
-
Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity.
Univerzálnost je nutnost. Téměř žádný projekt nepoužívá jen jeden jazyk.
Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit.
To není pravda. Existují balíčkovací systémy. Stačí nainstalovat pár balíčků a máte vše co potřebujete out of box. Základní konfiguraci vyřeší balíček better-defaults.
Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty.
Tak tohle je asi nějaký FUD, který šíří uživatelé moderních IDE. Vůbec nevím co tím chcete říct. Proč by mělo IDE řešit za programátora datové struktury?
Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.
Máte částečně pravdu, lépe se mi pracuje s klávesovými zkratkami Emacsu. Ty základní se dají nastavit i v jiných editorech. To stejné platí pro doplňky. JEDI, Rope a Pylint nebo flake8 se dají používat i v jiných editorech.
-
Ale stačil by i sed.
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Důležité je mít kód pokrytý testy.
Ano, po refaktoru sedem pak můžete hodiny opravovat rozbité testy.
-
...
Takže to samé co u kteréhokoliv moderního IDE, proč tedy takový odpor proti nim. Klávesové zkratky ala Vim, nebo Emacs většinou umí taky.
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
-
Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty.
Tak tohle je asi nějaký FUD, který šíří uživatelé moderních IDE. Vůbec nevím co tím chcete říct. Proč by mělo IDE řešit za programátora datové struktury?
Zřejmě pracuje s imperativními jazyky, ve kterých je občas nutné nějaké datové struktury vytvářet. V objektových jazycích obvykle použijeme nějakou hotovou třídu.
-
...
Takže to samé co u kteréhokoliv moderního IDE, proč tedy takový odpor proti nim. Klávesové zkratky ala Vim, nebo Emacs většinou umí taky.
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Až taková doba nastane, Emacs bude kdo to implementuje.
-
...
Takže to samé co u kteréhokoliv moderního IDE, proč tedy takový odpor proti nim. Klávesové zkratky ala Vim, nebo Emacs většinou umí taky.
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Až taková doba nastane, Emacs bude kdo to implementuje.
*Emacs bude první kdo to implementuje.
-
Takže to samé co u kteréhokoliv moderního IDE, proč tedy takový odpor proti nim. Klávesové zkratky ala Vim, nebo Emacs většinou umí taky.
Jaký odpor? Prostě nám Vim, resp. Emacs vyhovují lépe a nemáme důvod je měnit. Máme jen odpor proti neustálé reklamě na "moderní" IDE, které nás však omezuje. Často ani neumí přetěžovaná makra, na která jsem si ve Vimu zvykl.
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Taková doba už nastala. Jsem koučem svého Vimu.
-
Ale stačil by i sed.
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Důležité je mít kód pokrytý testy.
Ano, po refaktoru sedem pak můžete hodiny opravovat rozbité testy.
+1
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
-
;D
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
Pověz nám ještě něco o užitečnosti přejmenování metod. Na co bys chtěl přejmenovat metodu update()? A jak ti to moderní IDE pomůže změnit volání metody i v ostatních projektech, které tu třídu používají?
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
Pověz nám ještě něco o užitečnosti přejmenování metod. Na co bys chtěl přejmenovat metodu update()? A jak ti to moderní IDE pomůže změnit volání metody i v ostatních projektech, které tu třídu používají?
Ono kupodivu jmeno update() neni jedine mozne jmeno pro metodu. Jiste za domaci ukol najdes situace, kdy zmena jmena kodu prospeje.
Je trapne to zduraznovat, ale je rozdil mezi prejmenovavanim metod, ktere jsou a nejsou soucasti API modulu. Ze v jednom pripade neni dobre to delat, neznamena, ze to nema smysl obecne.
Ale jinak - budes mi tvrdit, ze pojmenujes metodu (tridu, funkci, promenou, konstantu...) a nenachazis po case duvod pouzit lepsi jmeno?
-
Pověz nám ještě něco o užitečnosti přejmenování metod. Na co bys chtěl přejmenovat metodu update()? A jak ti to moderní IDE pomůže změnit volání metody i v ostatních projektech, které tu třídu používají?
Ono kupodivu jmeno update() neni jedine mozne jmeno pro metodu. Jiste za domaci ukol najdes situace, kdy zmena jmena kodu prospeje.
Je trapne to zduraznovat, ale je rozdil mezi prejmenovavanim metod, ktere jsou a nejsou soucasti API modulu. Ze v jednom pripade neni dobre to delat, neznamena, ze to nema smysl obecne.
Ale jinak - budes mi tvrdit, ze pojmenujes metodu (tridu, funkci, promenou, konstantu...) a nenachazis po case duvod pouzit lepsi jmeno?
Pokud přejmenuji metodu, která není součástí API, tak je to změna čistě lokální a není nutné to sdělovat zbytku aplikace. Změna názvu metody může být zajímavá, pokud chci třídu zařadit mezi implementace nějakého rozhraní, které už nějaký název metody specifikuje.
Změny názvů tříd, metod a proměnných nedělám zase tak často, aby mě to motivovalo k přechodu na "moderní" IDE, které mi z mnoha dalších důvodů nevyhovuje. Ten zbytek v pohodě zvládnu i s Vimem na libovolném množství souborů. Tedy i takovém, na jakém ta IDE běžně kolabují.
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
ocividne je tu stret dvou svetu. stabilne navrzeneho ABI vs. moderni iterativni praseni.
-
sed nepomůže ani při jednoduchém přejmenování - stačí například, aby 1000 tříd mělo metodu update a v jedné z nich jste ji chtěl přejmenovat.
Pokud se ta metoda už používá na spoustě míst, tak ji nebudu přejmenovávat. Co bych tím získal? Když už by mi to přikázal nějaký nadřízaný fašista, tak bych použil Rope.
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
ocividne je tu stret dvou svetu. stabilne navrzeneho ABI vs. moderni iterativni praseni.
Přejmenování nemusí stabilitu ABI ani API nijak pokazit - např. v rámci projektu přejmenujete existující metodu update na unsafeUpdate a pro okolní svět vytvoříte novou metodu update.
-
ocividne je tu stret dvou svetu. stabilne navrzeneho ABI vs. moderni iterativni praseni.
Ne všichni píšou jenom knihovny. Pokud zákazníkovi řeknete, že to před deseti let chtěl takhle, tak to tak zůstane, protože to určitě předělávat nebudete, asi zákazníkem moc dlouho nebude.
-
Tak to bohužel neumíme, protože používáme na vývoj VIM.
:D
-
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
Nástroje mám. Fungují lépe než IDE od IntelliJ. Zde je video s ukázkou použití.
https://www.youtube.com/watch?v=BQ8D0heKLr4
-
Nástroje mám. Fungují lépe než IDE od IntelliJ. Zde je video s ukázkou použití.
https://www.youtube.com/watch?v=BQ8D0heKLr4
Co je na tom lepšího než IntelliJ?
-
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Taková doba už nastala. Jsem koučem svého Vimu.
Souhlas. Nástroje už dnes vykonávají otrockou práci. Aby za mě IDE generovalo kód, to je spíš krok zpět. Při použití normálního jazyka a dobrých knihoven k tomu není důvod.
-
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
Nástroje mám. Fungují lépe než IDE od IntelliJ. Zde je video s ukázkou použití.
https://www.youtube.com/watch?v=BQ8D0heKLr4
ROFL. OK, tak jestli to umí tohle, tak to musíte mít hodně spokojených zákazníků :D
-
Nástroje mám. Fungují lépe než IDE od IntelliJ. Zde je video s ukázkou použití.
https://www.youtube.com/watch?v=BQ8D0heKLr4
Co je na tom lepšího než IntelliJ?
Má to user friendly jednoduché rozhraní a funguje to i v terminálu.
-
Má to user friendly jednoduché rozhraní a funguje to i v terminálu.
Takže pro vás lépe. Pro mne je mnohem víc user friendly rozhraní Idea a že nefunguje v terminálu je mi úplně jedno.
-
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Taková doba už nastala. Jsem koučem svého Vimu.
Souhlas. Nástroje už dnes vykonávají otrockou práci. Aby za mě IDE generovalo kód, to je spíš krok zpět. Při použití normálního jazyka a dobrých knihoven k tomu není důvod.
Ty se doufám neživíš vývojem, že ne? Kit si lepí nějaké amatérské věci v PHP, tak tam chápu, že neumí vyvíjet. Ale to tvoje vypadá spíše max tak admin úroveň, kdy jsi schopný něco malého udělat a ještě špatně, ale na vývoj to není. Jako tamtomu říkat refactoring? To možná tak ve snu.
-
Protoze nemas dobre nastroje, tak nedelas neco, co je uzitecne. (Klasicky duvod je, ze casem k metode najdes o necovhodnejsi jmeno.) Je to jako bys nemel poradnou sekacku a tak bys tvrdil, ze nema cenu mit posekanou zahradu. Kdyz ti klesne cena takovyhle uprav diky dobrym nastrojum, tak muzes snado odstranovat i mensi problemy v kodu, protoze se to zacne vyplacet.
Nástroje mám. Fungují lépe než IDE od IntelliJ. Zde je video s ukázkou použití.
https://www.youtube.com/watch?v=BQ8D0heKLr4
Tak nekvic jako male dite a refaktoruj jako chlap!
ocividne je tu stret dvou svetu. stabilne navrzeneho ABI vs. moderni iterativni praseni.
a to pouzivani obratu "moderni iterativni praseni" je moderni zpusob pro "neumim/nechci zlepsovat existujici kod"?
Pokud zijes ve svete, kde se nemeni zadani, a pokud nedelas spatna rozhodnuti, tak nemusis svoje rozhodnuti iterovat. Kdyz v tomhle uzasnem svete nezijes a nejsi polobuh, tak proste iterujes a je na tobe, zda to chces nebo nechces vzit jako prileztost k tomu zlepsit kod
-
Má to user friendly jednoduché rozhraní a funguje to i v terminálu.
Takže pro vás lépe. Pro mne je mnohem víc user friendly rozhraní Idea a že nefunguje v terminálu je mi úplně jedno.
Dyť ten shit nic neumí. Srovnávat to s IDEA je docela drzost :D
-
Brzy přijde doba, kdy počítačům při tvorbě software budeme svěřovat mnohem více, než jen sestavení aplikace, kdy se z programátora stane coach.
Taková doba už nastala. Jsem koučem svého Vimu.
Souhlas. Nástroje už dnes vykonávají otrockou práci. Aby za mě IDE generovalo kód, to je spíš krok zpět. Při použití normálního jazyka a dobrých knihoven k tomu není důvod.
Ty se doufám neživíš vývojem, že ne? Kit si lepí nějaké amatérské věci v PHP, tak tam chápu, že neumí vyvíjet. Ale to tvoje vypadá spíše max tak admin úroveň, kdy jsi schopný něco malého udělat a ještě špatně, ale na vývoj to není. Jako tamtomu říkat refactoring? To možná tak ve snu.
Právě že živím. Praxe mě naučila nezabývat se blbostmi jako jména funkcí a ušetřený čas věnovat podstatným vylepšením.
-
Tak to je hlod dne ;D Jména funkcí jsou superdůležitá a pořád se mění podle vývoje architektury. Ale to ty vlastně dělat nemůžeš, protože nemáš nástroje. Nebo jak teda probíhá ten vývoj. Zjistíš, že půlka věcí se jmenuje blbě, tak to necháš a do dokumentace dáš, že se nemají lidi nechat zmást, ale že FileWriter s metodou seek čte z databáze?
-
ocividne je tu stret dvou svetu. stabilne navrzeneho ABI vs. moderni iterativni praseni.
a to pouzivani obratu "moderni iterativni praseni" je moderni zpusob pro "neumim/nechci zlepsovat existujici kod"?
Pokud zijes ve svete, kde se nemeni zadani, a pokud nedelas spatna rozhodnuti, tak nemusis svoje rozhodnuti iterovat. Kdyz v tomhle uzasnem svete nezijes a nejsi polobuh, tak proste iterujes a je na tobe, zda to chces nebo nechces vzit jako prileztost k tomu zlepsit kod
Nepleť si refaktoring s redesignem.
-
Právě že živím. Praxe mě naučila nezabývat se blbostmi jako jména funkcí a ušetřený čas věnovat podstatným vylepšením.
A doufas, ze az odejdes, tak tvuj nastupce nezjisti tvou adresu?
Tvuj problem je, ze nezijes ve svete, kde jsou tahle vylepseni prakticky zdarma. Kdyz musis kvuli nevhodnym nastrojum resit, zda to stoji za to, tak je nedelas (nebo delas vyjimecne).
-
Nepleť si refaktoring s redesignem.
Uz jednou jsem ti tu rikal, ze existuje refactoring to patterns.
Refactoring nejsou nutne jenom malicke, trivialni, lokalni zmeny.
-
Tak nekvic jako male dite a refaktoruj jako chlap!
Většinou jen malé děti řeší pojmenování funkcí.
a to pouzivani obratu "moderni iterativni praseni" je moderni zpusob pro "neumim/nechci zlepsovat existujici kod"?
Pokud zijes ve svete, kde se nemeni zadani, a pokud nedelas spatna rozhodnuti, tak nemusis svoje rozhodnuti iterovat. Kdyz v tomhle uzasnem svete nezijes a nejsi polobuh, tak proste iterujes a je na tobe, zda to chces nebo nechces vzit jako prileztost k tomu zlepsit kod
Zadání se mění často. Vždy mohu nějak ohnout existující API, tak aby zůstalo zpětně kompatibilní.
-
Nepleť si refaktoring s redesignem.
Uz jednou jsem ti tu rikal, ze existuje refactoring to patterns.
Refactoring nejsou nutne jenom malicke, trivialni, lokalni zmeny.
Refactoring nemění funkcionalitu. Pokud reaguješ na změnu zadání, tak je to redesign.
-
Nepleť si refaktoring s redesignem.
Uz jednou jsem ti tu rikal, ze existuje refactoring to patterns.
Refactoring nejsou nutne jenom malicke, trivialni, lokalni zmeny.
Refactoring nemění funkcionalitu. Pokud reaguješ na změnu zadání, tak je to redesign.
Reaguješ na změnu architektury refactoringem.
-
Dyť ten shit nic neumí. Srovnávat to s IDEA je docela drzost :D
Ale kdepak, umí toho dost. Umí i spoustu věcí, které IDEA neumí. Srovnávat to - ono je především každé určené na něco jiného. Ono i "vývoj software" zahrnuje spoustu různých věcí, pro vývoj kernelu, vývoj door page pro nový produkt a vývoj ERP nemusí být vhodné ty stejné nástroje. A i pro vývoj jednoho projektu mohou různým lidem vyhovovat různé nástroje.
-
Refactoring nemění funkcionalitu. Pokud reaguješ na změnu zadání, tak je to redesign.
Jsou ruzne zmeny zadani, na nektere reagujes refactoringem (zakaznik zacne jedne vei rikat jinak, tak prejmenovavas, napriklad), na nektere zmenou funkcionality, na nektere redesignem.
Zadání se mění často. Vždy mohu nějak ohnout existující API, tak aby zůstalo zpětně kompatibilní.
Pak pracujes s ohnutym kodem. Kolegove a tvoje budouci ja te museji milovat.
Ale samozrejme je otazka, zda ta zmena jde pres hranici modulu nebo ne, to hraje velkou roli.
-
Dyť ten shit nic neumí. Srovnávat to s IDEA je docela drzost :D
Ale kdepak, umí toho dost. Umí i spoustu věcí, které IDEA neumí. Srovnávat to - ono je především každé určené na něco jiného. Ono i "vývoj software" zahrnuje spoustu různých věcí, pro vývoj kernelu, vývoj door page pro nový produkt a vývoj ERP nemusí být vhodné ty stejné nástroje. A i pro vývoj jednoho projektu mohou různým lidem vyhovovat různé nástroje.
Ve videu byl skriptovací Python a refactoring v podstatě žádný. Tak asi špatné video...
-
Pak pracujes s ohnutym kodem. Kolegove a tvoje budouci ja te museji milovat.
Ale samozrejme je otazka, zda ta zmena jde pres hranici modulu nebo ne, to hraje velkou roli.
Pokud ta změna nejde přes hranici modulu, tak většinou nebývá problém ani ruční přejmenování. Kolegové mě mají raději než best practices fašisty, kteří jsou stále s něčím nespokojení.
-
Refactoring nemění funkcionalitu. Pokud reaguješ na změnu zadání, tak je to redesign.
Jsou ruzne zmeny zadani, na nektere reagujes refactoringem (zakaznik zacne jedne vei rikat jinak, tak prejmenovavas, napriklad), na nektere zmenou funkcionality, na nektere redesignem.
Stále to asi nechápeš. Pokud se mění rozhraní specifikované zákazníkem je to redesign. Pokud je to nějaká "věc", které zákazník začne říkat jinak, tak to bude nejspíš nějaký atribut a protože atributy bývají privátní, opravíš to v jedné třídě a jsi hotov. Nic rozsáhlého.
-
Dyť to říkám, tady asi těžko někdo umí vyvíjet... To je pak VIM luxusní zboží na takovou práci, to chápu.
-
No to mě po*er holý záda. Refaktoring je prostě refaktoring a funkčně se jím NIC nemění. Pokud u toho cokoliv funkčně změním, už do toho motám další operace, který NEJSOU refaktoring. A pro lopaty - zcela standardní linuxové příkazy jsou mnohem mocnější nástroj, než všechny moderní IDE dohromady. Když se usmyslím, překopu tím miliony souborů o celkové velikosti v řádu TB i více bez sebemenší obavy, že mi to v půlce spadne a já budu zbytek života trávit tím, že budu hledat, v jakým pořadí se to rozhodlo pracovat a kde to skončilo. A to vše bez potřeby mít na vývojovém stroji 128GB RAMky a víc. Stačí nebýt lopata a věnovat jedno odpoledne času, který jinak promrhám na rootu, na studium syntaxí a regulárních výrazů. Konkrétně vim, který většina lopat dodnes nepochopila a netuší ani, jak z něj odejít, má možnosti zcela nevídané, stačí si pročíst dokumentaci. To vše bez sebemenší potřeby hrábnout na myš, což je obzvlášť pro lidi, kteří píšou víc jak dvěma prsty, obrovská úspora času. Ale já vím, když je někdo tak dobrý, že má v hlavě kompletní javu, tak už se mu tam pár užitečných zkratek a příkazů prostě nevejde.
:%s/javaman/debil/g
-
OK, tak se tu pár lopat, které nic neumí, sešlo a kritizují IDE. To se dá chápat.
Ale co mi neni jasný, jak vy lopaty hledáte práci? To jim jako ukážete nějaký humus dělaný ve Vimu a vemou vás? Jako mně někdo přijít s tím, že dělá ve Vimu, tak si ho pořádně proklepnu, protože je to jasná lopata! Možná admin, který nevyvíjí a chtěl by začít.
-
OK, tak se tu pár lopat, které nic neumí, sešlo a kritizují IDE. To se dá chápat.
Ale co mi neni jasný, jak vy lopaty hledáte práci? To jim jako ukážete nějaký humus dělaný ve Vimu a vemou vás? Jako mně někdo přijít s tím, že dělá ve Vimu, tak si ho pořádně proklepnu, protože je to jasná lopata! Možná admin, který nevyvíjí a chtěl by začít.
To jsem rád, že to vím. Aspoň se mi nemůže stát, že bys mě zaměstnal.
-
Třeba si jen hraješ na neschopného a ve skutečnosti nejsi tak špatný. Kdo ví. Ale fakt bych chtěl vidět, jak tě třeba někdo veme na Javu, když bys jim ukázal svoje "IDE" :D Na Python by to šlo, tam se nic nevelkého nedělá.
-
No to mě po*er holý záda. Refaktoring je prostě refaktoring a funkčně se jím NIC nemění. Pokud u toho cokoliv funkčně změním, už do toho motám další operace, který NEJSOU refaktoring. A pro lopaty - zcela standardní linuxové příkazy jsou mnohem mocnější nástroj, než všechny moderní IDE dohromady. Když se usmyslím, překopu tím miliony souborů o celkové velikosti v řádu TB i více bez sebemenší obavy, že mi to v půlce spadne a já budu zbytek života trávit tím, že budu hledat, v jakým pořadí se to rozhodlo pracovat a kde to skončilo. A to vše bez potřeby mít na vývojovém stroji 128GB RAMky a víc. Stačí nebýt lopata a věnovat jedno odpoledne času, který jinak promrhám na rootu, na studium syntaxí a regulárních výrazů. Konkrétně vim, který většina lopat dodnes nepochopila a netuší ani, jak z něj odejít, má možnosti zcela nevídané, stačí si pročíst dokumentaci. To vše bez sebemenší potřeby hrábnout na myš, což je obzvlášť pro lidi, kteří píšou víc jak dvěma prsty, obrovská úspora času. Ale já vím, když je někdo tak dobrý, že má v hlavě kompletní javu, tak už se mu tam pár užitečných zkratek a příkazů prostě nevejde.
:%s/javaman/debil/g
Ty nemas projekty ve VCS?
Jinak regexpy ti uz z principu nepomohou. Nekdy zabrat mohou, ale obecne programy nejsou postizitelne regularnim jazykem.
-
OK, tak se tu pár lopat, které nic neumí, sešlo a kritizují IDE. To se dá chápat.
Ale co mi neni jasný, jak vy lopaty hledáte práci? To jim jako ukážete nějaký humus dělaný ve Vimu a vemou vás? Jako mně někdo přijít s tím, že dělá ve Vimu, tak si ho pořádně proklepnu, protože je to jasná lopata! Možná admin, který nevyvíjí a chtěl by začít.
Mně je zcela jedno, jaké kdo používá IDE. Není mi však jedno, když se do mne někdo naváží jen proto, že používám Vim.
Zdrojáky napsané ve Vimu vypadají luxusně. Když to čtenáři neřekneš, tak nepozná, v jakém editoru to bylo napsáno. Ono je to stejně jedno, protože filtry v Gitu to uloží do repozitáře podle nastaveného standardu pro daný projekt.
-
Tak pokud bys opravdu v něm dělal, tak jen budeš brutálně pomalý. Takže je zbytečné tě vůbec zaměstnávat, ale jinak je mi to také jedno. Si používej klidně Notepad, také to jde. Jsem jen myslel, jaké jsou argumenty proti IDE. Evidentně jen neznalost.
OK, pokud to tak funguje, tak by to šlo. Ve Vimu ale budou spíše dělat patlalové, které jeden prázdný řádek navíc nerozhází a celkově to nebude žádný vývoj.
-
Jinak regexpy ti uz z principu nepomohou. Nekdy zabrat mohou, ale obecne programy nejsou postizitelne regularnim jazykem.
Pokud nejsi programátorské čuně, tak si s tím regulárním jazykem vystačíš i na základním levelu. Pokud dostáváš zdrojáky od čuněte, přestyluješ si je filtrem smudge.
-
Pokud nejsi programátorské čuně, tak si s tím regulárním jazykem vystačíš i na základním levelu. Pokud dostáváš zdrojáky od čuněte, přestyluješ si je filtrem smudge.
Tak to bych rád viděl regexp na tohle:
class A {
void update();
};
class B {
void update();
};
main() {
A a; B b;
a.update();
b.update();
}
chci změnit na:
class A {
void update();
};
class B {
void update2();
};
main() {
A a; B b;
a.update();
b.update2();
}
S regexpem jsi skončil.
-
S regexpem jsi skončil.
Určitě jsi jen zapomněl na smudge filter ;D
-
Ty nemas projekty ve VCS?
Jinak regexpy ti uz z principu nepomohou. Nekdy zabrat mohou, ale obecne programy nejsou postizitelne regularnim jazykem.
Prosím, prosím, prosím, řekni, že seš vožralej a nevíš, co mluvíš. Mám tě za celkem inteligentního polotrolla, ale jestli tohle myslíš vážně, tak ti to neodpustím. Co nedokáže kombinace sed, awk, grep, cat, head, tail a nástroje vimu, to rozhodně líp nedokáže žádný IDE. Tak to prostě je a jestli tomu nevěříš, tak je to tím, že netušíš, jaký to má možnosti. Doporučuji studium.
-
Pokud nejsi programátorské čuně, tak si s tím regulárním jazykem vystačíš i na základním levelu. Pokud dostáváš zdrojáky od čuněte, přestyluješ si je filtrem smudge.
Tak to bych rád viděl regexp na tohle:
class A {
void update();
};
class B {
void update();
};
main() {
A a; B b;
a.update();
b.update();
}
chci změnit na:
class A {
void update();
};
class B {
void update2();
};
main() {
A a; B b;
a.update();
b.update2();
}
S regexpem jsi skončil.
Pokud pojmenováváš instance rozumně jako v tomhle případě, tak je regexp jasná volba.
-
Pokud pojmenováváš instance rozumně jako v tomhle případě, tak je regexp jasná volba.
Tohle už je jen trolling, že? Protože tohle nemůže myslet normální člověk vážně...
-
Ty nemas projekty ve VCS?
Jinak regexpy ti uz z principu nepomohou. Nekdy zabrat mohou, ale obecne programy nejsou postizitelne regularnim jazykem.
Prosím, prosím, prosím, řekni, že seš vožralej a nevíš, co mluvíš. Mám tě za celkem inteligentního polotrolla, ale jestli tohle myslíš vážně, tak ti to neodpustím. Co nedokáže kombinace sed, awk, grep, cat, head, tail a nástroje vimu, to rozhodně líp nedokáže žádný IDE. Tak to prostě je a jestli tomu nevěříš, tak je to tím, že netušíš, jaký to má možnosti. Doporučuji studium.
Chomskeho hierarchie nic nerika? (Pro uplnost dodavam, ze awkckem z tohohle muzes za cenu nejakych obeti vybrousit, protoze tam mas while, ale to je vazne jenom moznost pro zoufalce.)
-
Pokud pojmenováváš instance rozumně jako v tomhle případě, tak je regexp jasná volba.
Tohle už je jen trolling, že? Protože tohle nemůže myslet normální člověk vážně...
Proč ne? Nejdřív si grepem nebo ack vypíšu všechny použití. Zjistím si, pro jaké instance to chci změnit a podle toho napíšu regexp. Pokud by těch případů bylo moc, tak není dobrý nápad to měnit.
-
Pokud pojmenováváš instance rozumně jako v tomhle případě, tak je regexp jasná volba.
Tohle už je jen trolling, že? Protože tohle nemůže myslet normální člověk vážně...
Proč ne? Nejdřív si grepem nebo ack vypíšu všechny použití. Zjistím si, pro jaké instance to chci změnit a podle toho napíšu regexp. Pokud by těch případů bylo moc, tak není dobrý nápad to měnit.
Takze nedostatecne nastroje zpusobi to, ze neudelas jinak uzitecnou upravu...
-
Prosím, prosím, prosím, řekni, že seš vožralej a nevíš, co mluvíš. Mám tě za celkem inteligentního polotrolla, ale jestli tohle myslíš vážně, tak ti to neodpustím. Co nedokáže kombinace sed, awk, grep, cat, head, tail a nástroje vimu, to rozhodně líp nedokáže žádný IDE. Tak to prostě je a jestli tomu nevěříš, tak je to tím, že netušíš, jaký to má možnosti. Doporučuji studium.
Studium potřebuješ spíš ty, k rozumnému refactoringu potřebuješ něco jako AST: https://en.wikipedia.org/wiki/Abstract_syntax_tree a ten nikdy v sedu mít nebudeš, IDE ho mají (pro Kita: dá se dostat přes externí tooly i do vimu ;))
-
Pokud pojmenováváš instance rozumně jako v tomhle případě, tak je regexp jasná volba.
Tohle už je jen trolling, že? Protože tohle nemůže myslet normální člověk vážně...
Proč ne? Nejdřív si grepem nebo ack vypíšu všechny použití.
Použití může být poměrně těžké poznat z malého kontextu - např. v kódu může být getEntity().update() - na první pohled není vidět, z jaké třídy je metoda update(). Navíc se můžete snadno splést a něco opomenout nahradit nebo naopak nahradit něco, co by se nahradit nemělo.
-
Studium potřebuješ spíš ty, k rozumnému refactoringu potřebuješ něco jako AST: https://en.wikipedia.org/wiki/Abstract_syntax_tree a ten nikdy v sedu mít nebudeš, IDE ho mají (pro Kita: dá se dostat přes externí tooly i do vimu ;))
Teoreticky ano. Prakticky se bez toho dá žít.
-
Prosím, prosím, prosím, řekni, že seš vožralej a nevíš, co mluvíš. Mám tě za celkem inteligentního polotrolla, ale jestli tohle myslíš vážně, tak ti to neodpustím. Co nedokáže kombinace sed, awk, grep, cat, head, tail a nástroje vimu, to rozhodně líp nedokáže žádný IDE. Tak to prostě je a jestli tomu nevěříš, tak je to tím, že netušíš, jaký to má možnosti. Doporučuji studium.
To spíš vypadá, že nevíte, co umí IDE nebo alespoň lepší programátorský editor. Jak dokážete pomocí těch vašich nástrojů během pár vteřin vytvořit předka třídy, přetáhnout do něj vybrané metody a všude, kde to jde, použít místo refaktorované třídy toho předka? Jak třeba v Javě přidáte parametr funkcionálnímu rozhraní? Jak pomocí regulárního výrazu uděláte takovou prkotinu, jako přejmenování jedné metody, pokud máte stejně pojmenovanou metodou v jiných třídách?
-
Použití může být poměrně těžké poznat z malého kontextu - např. v kódu může být getEntity().update() - na první pohled není vidět, z jaké třídy je metoda update(). Navíc se můžete snadno splést a něco opomenout nahradit nebo naopak nahradit něco, co by se nahradit nemělo.
A Kit ještě psal, že název update dává úplně všemu, takže o to to bude horší...
Studium potřebuješ spíš ty, k rozumnému refactoringu potřebuješ něco jako AST: https://en.wikipedia.org/wiki/Abstract_syntax_tree a ten nikdy v sedu mít nebudeš, IDE ho mají (pro Kita: dá se dostat přes externí tooly i do vimu ;))
Teoreticky ano. Prakticky se bez toho dá žít.
Prakticky jsi pak lopata, která toho moc neudělá a na pozice za 100+ můžeš zapomenout. Ale bez toho se taky dá žít.
-
Studium potřebuješ spíš ty, k rozumnému refactoringu potřebuješ něco jako AST: https://en.wikipedia.org/wiki/Abstract_syntax_tree a ten nikdy v sedu mít nebudeš, IDE ho mají (pro Kita: dá se dostat přes externí tooly i do vimu ;))
Teoreticky ano. Prakticky se bez toho dá žít.
Prakticky opet ne. Protoze po nastrojich na praci s kodem chces, aby fungovaly. Ne aby fungovaly nekdy.
Jinak se zase dostanes obloukem k tomu, ze kod nezlepsujes, protoze je to tezke a tezke to je, protoze nemuzes verit nastrojum a musis pri tom hazet lopatou rucne.
-
Pokud nejsi programátorské čuně, tak si s tím regulárním jazykem vystačíš i na základním levelu. Pokud dostáváš zdrojáky od čuněte, přestyluješ si je filtrem smudge.
Tak to bych rád viděl regexp na tohle:
...
S regexpem jsi skončil.
A jsme zase u toho hloupého přejmenovávání. To si pod pojmem "refactoring" neumíš představit něco jiného?
Vzhledem k tomu, že přejmenování metod dělám minimáně, klidně to udělám ručně přes '*'. Na těch několika řádcích není co řešit a testy to jistí. Ovšem přejmenovávat update() na update2() je opravdu hloupý nápad.
Kromě toho v C++ nedělám, ale nenapadlo by mě dát dva příkazy na jeden řádek. Program indent mi to automaticky rozhodil na dva.
-
Takze nedostatecne nastroje zpusobi to, ze neudelas jinak uzitecnou upravu...
Co je na změně názvu metody užitečného?
-
Prosím, prosím, prosím, řekni, že seš vožralej a nevíš, co mluvíš. Mám tě za celkem inteligentního polotrolla, ale jestli tohle myslíš vážně, tak ti to neodpustím. Co nedokáže kombinace sed, awk, grep, cat, head, tail a nástroje vimu, to rozhodně líp nedokáže žádný IDE. Tak to prostě je a jestli tomu nevěříš, tak je to tím, že netušíš, jaký to má možnosti. Doporučuji studium.
To spíš vypadá, že nevíte, co umí IDE nebo alespoň lepší programátorský editor. Jak dokážete pomocí těch vašich nástrojů během pár vteřin vytvořit předka třídy, přetáhnout do něj vybrané metody a všude, kde to jde, použít místo refaktorované třídy toho předka? Jak třeba v Javě přidáte parametr funkcionálnímu rozhraní? Jak pomocí regulárního výrazu uděláte takovou prkotinu, jako přejmenování jedné metody, pokud máte stejně pojmenovanou metodou v jiných třídách?
Myslíš tohle?
https://github.com/python-rope/rope/blob/master/docs/overview.rst#move-method-refactoring
Dosud jsme se bavili o prostém přejmenování funkce. K tomu stačí jednoduší nástroje.
Použití může být poměrně těžké poznat z malého kontextu - např. v kódu může být getEntity().update() - na první pohled není vidět, z jaké třídy je metoda update(). Navíc se můžete snadno splést a něco opomenout nahradit nebo naopak nahradit něco, co by se nahradit nemělo.
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
-
Když jsem vám to před tím říkal, tak jste mi nevěřili. Tohle mi přijít na pohovor, tak si fakt myslím, že je to nějaká zadek a hledal bych skrytou kameru :D
-
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
A pak dalsich par vterin na neco jineho. A jinych par vterin tam... a z trivilaniho zasahu je prace.
To je vazne tak obtizne v jedenadvacatem stoleti prijmout myslenku, ze by se prace mela nechat strojum? Zejmena, pokud ji zvladnou spolehliveji, rychleji a bez zbytecnych kecu?
-
A jsme zase u toho hloupého přejmenovávání. To si pod pojmem "refactoring" neumíš představit něco jiného?
Vzhledem k tomu, že přejmenování metod dělám minimáně, klidně to udělám ručně přes '*'. Na těch několika řádcích není co řešit a testy to jistí. Ovšem přejmenovávat update() na update2() je opravdu hloupý nápad.
Kromě toho v C++ nedělám, ale nenapadlo by mě dát dva příkazy na jeden řádek. Program indent mi to automaticky rozhodil na dva.
Kite, už se neztrapňuj, radší toho nech. Všichni vědí, že němáš zkušenosti s velkými projekty a tvůj nejoblíbenější design pattern je Cargo cult programming, nicméně nemusíš nás o tom pořád dokola utvrzovat.
Co se týká argumentů tak: regexp selže už jen na hloupé přejmenování metody, na co složitějšího bys ho chtěl ještě použít? update -> update2 byl jen příklad, klidně si pod tím představ update -> kitovo_oblibene_jmeno_pro_metodu. Kolik příkazů je na jednom řádku je naprosto irelevantní, refactoring musí fungovat, i když budu mít 1000 příkazů na jednom řádku.
-
Použití může být poměrně těžké poznat z malého kontextu - např. v kódu může být getEntity().update() - na první pohled není vidět, z jaké třídy je metoda update(). Navíc se můžete snadno splést a něco opomenout nahradit nebo naopak nahradit něco, co by se nahradit nemělo.
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Pár vteřin je ale docela dost dlouhá doba - kdybyste použil IDE, tak byste za pár vteřin měl přejmenováno.
-
A jsme zase u toho hloupého přejmenovávání. To si pod pojmem "refactoring" neumíš představit něco jiného?
Ne, je to proste jenom snadny a jednoduse pochopitelny protipriklad. Ze jsou i slozitejsi neni zas tak prekvapive.
-
Takze
- kdo tvrdi, ze to umi regexpy bud lze nebo nezna zaklady teoreticke informatiky a tak se "jenom" plete
- kdo tvrdi, ze mu podobne upravy neprijdou uzitecne... mno rekneme, ze jini lide resi i situace, kdy to uzitecne je. Dost.
- kdo tvrdi, ze "to nestoji za tu namahu" nema nastroje, kde to jde bez namahy.
(btw: ja bych se vubec nezlobil, kdyby existovala dospela sada nastroju, ktera by to zvladala z lajny nebo z vimka... Ale dokud mi je nikdo neda, tak budu dal pouzivat to, co funguje.)
-
(btw: ja bych se vubec nezlobil, kdyby existovala dospela sada nastroju, ktera by to zvladala z lajny nebo z vimka... Ale dokud mi je nikdo neda, tak budu dal pouzivat to, co funguje.)
Celou dobu tady mluvím o Rope. Pokud vím, dá se to dobře používat i z ipythonu. Ale není důvod. Existují pluginy pro všechny populární editory.
-
(btw: ja bych se vubec nezlobil, kdyby existovala dospela sada nastroju, ktera by to zvladala z lajny nebo z vimka... Ale dokud mi je nikdo neda, tak budu dal pouzivat to, co funguje.)
Celou dobu tady mluvím o Rope. Pokud vím, dá se to dobře používat i z ipythonu. Ale není důvod. Existují pluginy pro všechny populární editory.
No vzhledem k tomu, ze jedu i Javu, Scalu a Haskell, tak mi reseni pouze pro Python moc neimponuje (teoreticky bych ho mohl zacit pouzivat na Python, ale kdyz mam PyCharm, ktery se podoba IntelliJ, tak nema smysl pouzivat extra reseni pro jediny jazyk).
-
Hlavně pochybuju, že to může u Pythonu fungovat. Tam plno věcí mineš. Proto se Python nepoužívá na velké věci.
-
Myslíš tohle?
https://github.com/python-rope/rope/blob/master/docs/overview.rst#move-method-refactoring
Ne, myslím tohle:
class Child(object):
def a_method(self):
pass
def b_method(self):
pass
child1 = Child()
child1.a_method()
child2 = Child()
child2.a_method()
child2.b_method()
Po refaktorování:
class Parent(object):
def a_method(self):
pass
class Child(Parent):
def b_method(self):
pass
parent1 = Parent()
parent1.a_method()
child2 = Child()
child2.a_method()
child2.b_method()
Dosud jsme se bavili o prostém přejmenování funkce. K tomu stačí jednoduší nástroje.
O pouhém přejmenování se asi baví jenom ti, kteří tvrdí, že si vystačí s regulárními výrazy. A navíc tu pořád nikdo neukázal, jak bude pomocí regulárního výrazu automaticky přejmenovávat metodu, když stejně pojmenovanou metodu bude mít v desítkách dalších tříd.
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?
-
No vzhledem k tomu, ze jedu i Javu, Scalu a Haskell, tak mi reseni pouze pro Python moc neimponuje (teoreticky bych ho mohl zacit pouzivat na Python, ale kdyz mam PyCharm, ktery se podoba IntelliJ, tak nema smysl pouzivat extra reseni pro jediny jazyk).
Mám nainstalovány podobné pluginy i pro jiné jazyky, ale moc je nepoužívám.
-
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?
Měnit stovky výskytů volání metody jedné třídy v ostatních třídách? To smrdí špatným návrhem aplikace.
-
Měnit stovky výskytů volání metody jedné třídy v ostatních třídách? To smrdí špatným návrhem aplikace.
No jasne. A spatne navrhovane aplikace refaktorovat nebudeme...
-
Měnit stovky výskytů volání metody jedné třídy v ostatních třídách? To smrdí špatným návrhem aplikace.
No jasne. A spatne navrhovane aplikace refaktorovat nebudeme...
Na takové aplikaci bude nutné udělat takovou spoustu jiných změn, že nějaké přejmenování metody bude jen prkotinou a nejspíš taková metoda přitom zcela zanikne.
-
Na takové aplikaci bude nutné udělat takovou spoustu jiných změn, že nějaké přejmenování metody bude jen prkotinou a nejspíš taková metoda přitom zcela zanikne.
Tak si tam predstav nejaky jiny refaktoring...
Cim sofistikovanejsi bude, tim hur na tom budes s nastroji, ktere doopravdy nerozumi kodu.
-
Třeba tak triviální věc jako přidat do celého projektu/všech tříd chybějící užitečnou anotaci @Override. S IDE práce na chviličku, jen ten commit bude obsahovat třeba pár tisíc souborů (což je taky na chviličku).
Nebo hlídání anotací @Nullable a @Nonnull a spol.
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu. A není potřeba kontrolovat kompilovatelnost, ta je prostě zajištěna. A vše je to otázka několika sekund.
Samozřejmě úplná spolehlivost vyžaduje vyhýbat se mapováním stringů na názvy (PropertyModel ve Wicketu apod.). IDEA se to sice snaží hledat a nabízet, ale to už je cesta do pekla...
-
Ještě mě překvapuje, že profesionální vývojář, který očekává příjem mnoha desítek tisíc Kč, řeší paměťovou náročnost vývojového nástroje. V době, kdy lze profi pracovní stanice se 128GB ECC DDR3 RAM pořídit za 20k Kč bez DPH.
-
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..
Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity. Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit. Taky vás nasměrují určitým směrem, investujete do nich hodně práce, takže ten směr změnit bude pro vás složité, časem se stane neoptimální, ale na jeho změnu díky předešlým investicím, nikdy nepřistoupíte. Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty. Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.
Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.
Ono se to nezdá, ale systém pro vytváření aplikací je v 98% de facto mnohem složitější systém, než výsledná aplikace a to bez ohledu na základ, který k němu použijete.
Tohle jsem moc nepobral. Mě teda nepříde efektivní vyvíjet kvůli každému projektu zvlášť specializované IDE. Komplexní IDE je sice složitější než většina aplikací (alespoň mých), ale zas těch aplikací v něm udělám desítky, možná stovky, takže ve výsledku se to komplexní IDE vyplatí.
Samozřejmě, že jeden jediný člověk za svůj život nevyvine komplexní IDE typu NEtBeans bez ohledu na to, jaký základ použije. To přece není o Emacsu nebo Vimu, to asi platí obecně.
Zakopaný pes je taky v datových strukturách... - ty seš taky struktura...
-
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..
A ty svůj kód dáš na první dobrou? Než něco commituju, musí to nějak vypadat, abych se za něj nemusel stydět a nezvonilo mi v uších, až to po mně někdo jiný nebo i já sám bude upravovat/rozšiřovat/aktualizovat/prostě vyvýjet dál. Ty změny se vůbec nemusí týkat nějakého API, i kód vnitřní implementace je klíčový. I taková zvěrstva tu zazněla, že na vnitřním kódu vlastně nezáleží.
-
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..
A ty svůj kód dáš na první dobrou? Než něco commituju, musí to nějak vypadat, abych se za něj nemusel stydět a nezvonilo mi v uších, až to po mně někdo jiný nebo i já sám bude upravovat/rozšiřovat/aktualizovat/prostě vyvýjet dál. Ty změny se vůbec nemusí týkat nějakého API, i kód vnitřní implementace je klíčový. I taková zvěrstva tu zazněla, že na vnitřním kódu vlastně nezáleží.
Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.
-
Ještě mě překvapuje, že profesionální vývojář, který očekává příjem mnoha desítek tisíc Kč, řeší paměťovou náročnost vývojového nástroje. V době, kdy lze profi pracovní stanice se 128GB ECC DDR3 RAM pořídit za 20k Kč bez DPH.
Jestli to byla narážka na můj příspěvek, tak za prvé, nejsem profesionální vývojář, za druhé, zeptej se, na čem lidi běžně pracují, za třetí, ukaž mi tu profi stanici za ty peníze. Ať počítám, jak počítám, jenom paměť bude bratru za 12k, takže jestli k tomu seženeš desku, která to pobere, rozumný CPU, disk a case se zdrojem za 8k, tak nevím, jestli bych to nazval zrovna profi, to se dostáváme někam k totálnímu low endu, na kterým bych opravdu nechtěl kompilovat větší projekt, se kterým kompletně cvičíš.
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?
-
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..
Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity. Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit. Taky vás nasměrují určitým směrem, investujete do nich hodně práce, takže ten směr změnit bude pro vás složité, časem se stane neoptimální, ale na jeho změnu díky předešlým investicím, nikdy nepřistoupíte. Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty. Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.
Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.
Ono se to nezdá, ale systém pro vytváření aplikací je v 98% de facto mnohem složitější systém, než výsledná aplikace a to bez ohledu na základ, který k němu použijete.
Tohle jsem moc nepobral. Mě teda nepříde efektivní vyvíjet kvůli každému projektu zvlášť specializované IDE. Komplexní IDE je sice složitější než většina aplikací (alespoň mých), ale zas těch aplikací v něm udělám desítky, možná stovky, takže ve výsledku se to komplexní IDE vyplatí.
Samozřejmě, že jeden jediný člověk za svůj život nevyvine komplexní IDE typu NEtBeans bez ohledu na to, jaký základ použije. To přece není o Emacsu nebo Vimu, to asi platí obecně.
Zakopaný pes je taky v datových strukturách... - ty seš taky struktura...
Specializované IDE - zná jazyk, během editování buduje AST, umí sestavit aplikaci, klidně v jednom IDE má x jazyků. Univerzální IDE - editor + nástroje na úpravu textu, typicky regex, vlastní skripty por úpravy, vlastní skripty pro sestavení aplikace. Obvykle zatížené bašismem a copy&paste.
A ta datová struktura, kolem které se točí práce v IDE je je to AST a další potřebné pro sestavení úlohy. Vtip je v tom, že IDE můžete vyměnit, každé IDE si načte projekt a samo si vytvoří potřebné datové interní struktury.
Když používáte vim, nebo emacs, taky takto můžete postupovat, ale zcela určitě nepostupujete, vše vyřešíte skripty, lépe řečeno šablonami skriptů, které upravujete na konkrétní podmínky použití, takže když je třeba něco podstatného změnit, musíte upravit všechny skripty, nemáte prostředky k tomu, aby se vygenerovaly automaticky, bez detailní znalosti projektu se neobejdete.
-
Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.
Máš zkušenosti s větším živým projektem (pár tisíc tříd), který se roky iterativně posouvá dopředu dle aktuálních byznys požadavků? Pak zjistíš, že správná funkčnost kódu je jenom minimálním požadavkem. Minimálně stejně důležitým je možnost ten kód dál vyvíjet, používat, rozšiřovat. V tom je jeho hodnota. Jinak jej při každé změně budu muset zahodit a napsat to znovu. S tím souvisí základní věci - správná pojmenování všeho (a ne, opravdu na první dobrou nelze tohle dát, protože ten finální kód se od první verze zcela liší), krátké jednoduché metody (při vývoji vzniklé špagety je potřeba rozpadnout do metod - opět práce pro IDE), atd. atd. Překvapuje mě, že tohle ještě vůbec někdo v dnešní době může neznat.
Samozřejmě pokud je cílem dodat zkompilovanou binárku klientovi, vykešovat a nazdar, pak je to jedno.
-
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?
Pokud na takovém projektu pracuje víc než jeden vývojář, tak skutečně musí být velmi zajímavou prací řešení kolizí na Gitu. Sledovat stovky změn souborů v každém commitu, to musí být také slušný zážitek. Tomu jistě bude odpovídat i kvalita komentů.
-
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?
Měnit stovky výskytů volání metody jedné třídy v ostatních třídách? To smrdí špatným návrhem aplikace.
No vždyť ano, právě proto se dělá refaktoring, aby se změnil nevhodný návrh aplikace. A právě proto je potřeba mít nástroje, se kterými se refaktoring udělá snadno, rychle a spolehlivě - protože jinak ten nevhodný návrh nikdo neopraví, protože to přece ještě nestojí za tu námahu, a nevhodný návrh se v aplikaci zakonzervuje.
Na takové aplikaci bude nutné udělat takovou spoustu jiných změn, že nějaké přejmenování metody bude jen prkotinou a nejspíš taková metoda přitom zcela zanikne.
Což ale není důvod, aby tou prkotinou někdo strávil několik dní. Právě naopak, je dobře, když tu prkotinu udělá programátor rychle a správně, a pak může svůj čas věnovat významovým změnám kódu, které žádný automat neudělá.
-
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu
Výhoda toho, že to netrvá hodiny, ale pár vteřin, není v tom, že byste to prováděl několikrát za hodinu. Výhoda je, že to uděláte za pár vteřin a ty bývající hodiny můžete dělat něco produktivního. A hlavní výhoda je, že se do toho díky té rychlosti a spolehlivosti vůbec pustíte, takže se nezvětšuje technologický dluh.
-
Pokud na takovém projektu pracuje víc než jeden vývojář, tak skutečně musí být velmi zajímavou prací řešení kolizí na Gitu. Sledovat stovky změn souborů v každém commitu, to musí být také slušný zážitek. Tomu jistě bude odpovídat i kvalita komentů.
Není důvod, aby takhle vznikalo velké množství kolizí. A Git je právě výborný nástroj na to, že většinu potenciálních kolizí vyřeší sám, a pokud se někde vývojáři opravdu sejdou na stejném kódu, umožňuje to snadno vyřešit.
Nevím, proč by měl někdo sledovat stovky změn souborů v commitu. Že jde o refaktoring se dozvím z komentáře, a kontrolovat očima po IDE, že to provedlo správně, to opravdu nemusím.
-
Jestli to byla narážka na můj příspěvek, tak za prvé, nejsem profesionální vývojář,
Pak asi neřešíš rozsáhlé projekty, o kterých je tu řeč a nepotřebuješ to.
zeptej se, na čem lidi běžně pracují
To je věc každého, co si pořídí. Nebo jejich vedení. Hardware lze dnes pořídit téměř zadarmo, v porovnání s platem vývojářů.
ukaž mi tu profi stanici za ty peníze.
Velice snadno, tady jsem ji včera popisoval http://forum.root.cz/index.php?topic=13639.msg174011#msg174011. Jen se DIMMy nakombinují 7x16GB + 2 x 8GB a cena se do 20k bez DPH vejde.
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu
Nepsal jsem, že několikrát za hodinu mění metody objektů použitých skrz celý projekt, ale že pořád dokola používá funkce na přejmenování/přesuny/rozpad do metod atd. Vývoj je přece iterativní, hrubá kostra, a pak se to dolaďuje, zjednodušuje, upravuje tak, aby šlo využít na více místech. To vše klidně v rámci pár tříd, které ve finálu vyřeší požadavek, na kterým zrovna dělám. A částí, na kterých dělají ostatní, se to nijak netýká.
a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?
Co konkrétně myslíš pod "lidi, kteří řeší správu gitu"? Git si samozřejmě řeší každý vývojář sám, dělá si commity, pravidelně stahuje commity z centrálního repo a když to své má hotové (od jednoho do třeba i sto commitů, ale to už by určitě dělal do větve), pushne to ostatním na centrální repo. Ano, může dojít ke konfliktu, ale od toho tam sedí spolu, aby si to pořešili. V praxi k tomu dochází zcela minimálně a je to standardní součástí týmového vývoje.
Překvapuje mě, jak se tady lidi brání čištění/aktualizaci kódu. Už jen tím, že se brání nástrojům, které jim to dovolí. Přitom to je to, na čem celý den dělají, s čím žijí. A dělat celý den na bordelu, to je přece smutný život.
Je pravda, že tenhle zcela zásadní aspekt práce vývojáře se na vejškách takřka neřeší. Zřejmě proto, že učitelé sami na žádných větších projektech nikdy nedělali a nemuseli se tím nikdy zabývat. Ale já to považuju za úplně zásadní, zcela stejně důležité jako správnou funkčnost. Přijde mi, že by tohle mělo být součástí profesní hrdosti vývojáře - když se na můj finální (tj. commitovaný) kód podívám, musím z něj mít radost a jo, být na něj trochu hrdý. Sračka typu "je to jedno, hlavně že to funguje a splnil jsem tak zadání" musí dlouhodobě lézt na mozek.
Navíc jsem ten, kdo ten vývojový tým ve své firmě platí, takže mám sakra velký zájem, aby výsledný kód měl dlouhodobou hodnotu, a nejenom jednorázový bastl, který pak vyhodím a zaplatím někomu jinému za napsání znovu.
-
Překvapuje mě, jak se tady lidi brání čištění/aktualizaci kódu. Už jen tím, že se brání nástrojům, které jim to dovolí. Přitom to je to, na čem celý den dělají, s čím žijí. A dělat celý den na bordelu, to je přece smutný život.
Tady se přece nikdo nebrání čistění/aktualizaci kódu. Jen se pozastavujeme nad tím, že všechny zde uvedené ukázky dělají ze špinavého kódu úplně stejně špinavý kód. A takové "čistění" opravdu dělat nemusím.
-
Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.
-
Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.
To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.
-
Tady se přece nikdo nebrání čistění/aktualizaci kódu. Jen se pozastavujeme nad tím, že všechny zde uvedené ukázky dělají ze špinavého kódu úplně stejně špinavý kód. A takové "čistění" opravdu dělat nemusím.
To je ale nepochopení refaktoringu. Refaktoring není zlepšování kódu. Refaktoring je příprava kódu na to, abych ho mohl zlepšit. Třeba to přejmenování metody samo o sobě samozřejmě kód nezlepší. Ale umožní mi to třeba vedle vytvořit novou metodu, která bude dělat něco podobného, jako ta původní - a přejmenováním je od sebe dokážu odlišit. Nebo to vytažení části implementace do předka (nebo jenom vytvoření abstraktního předka) mi umožní využít společný kód i v dalších třídách.
-
Tady se přece nikdo nebrání čistění/aktualizaci kódu. Jen se pozastavujeme nad tím, že všechny zde uvedené ukázky dělají ze špinavého kódu úplně stejně špinavý kód. A takové "čistění" opravdu dělat nemusím.
To je ale nepochopení refaktoringu. Refaktoring není zlepšování kódu. Refaktoring je příprava kódu na to, abych ho mohl zlepšit. Třeba to přejmenování metody samo o sobě samozřejmě kód nezlepší. Ale umožní mi to třeba vedle vytvořit novou metodu, která bude dělat něco podobného, jako ta původní - a přejmenováním je od sebe dokážu odlišit. Nebo to vytažení části implementace do předka (nebo jenom vytvoření abstraktního předka) mi umožní využít společný kód i v dalších třídách.
Souhlasím, že refaktoring je přípravou na redesign.
Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.
-
Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.
Každé je ale něco jiného. Ze současné třídy dělám předka tehdy, když ji potřebuji dál specializovat. Jiný případ je, když už speciální třídu mám, ale obsahuje v sobě i obecný kód - protože původně byla specializovaná třída jen jedna a nebyl důvod psát předka jen tak do foroty. Pak z té třídy potřebuju vytáhnout do předka jenom tu obecnou část a speciální ponechat.
-
Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.
Každé je ale něco jiného. Ze současné třídy dělám předka tehdy, když ji potřebuji dál specializovat. Jiný případ je, když už speciální třídu mám, ale obsahuje v sobě i obecný kód - protože původně byla specializovaná třída jen jedna a nebyl důvod psát předka jen tak do foroty. Pak z té třídy potřebuju vytáhnout do předka jenom tu obecnou část a speciální ponechat.
Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka. V předkovi je nahradím obecnějšími nebo abstraktními metodami, abych neporušil LSP.
Pokud ta tvá třída obsahuje obecný kód, zamyslel bych se spíš nad kompozicí než nad dědičností. Tím se ten tvůj kód stane mnohem obecnějším, protože nebude fixován na jednu třídu.
-
Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka.
V tomhle okamžiku jste rozbil veškerý kód, který na té speciální části závisel.
-
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..
A ty svůj kód dáš na první dobrou? Než něco commituju, musí to nějak vypadat, abych se za něj nemusel stydět a nezvonilo mi v uších, až to po mně někdo jiný nebo i já sám bude upravovat/rozšiřovat/aktualizovat/prostě vyvýjet dál. Ty změny se vůbec nemusí týkat nějakého API, i kód vnitřní implementace je klíčový. I taková zvěrstva tu zazněla, že na vnitřním kódu vlastně nezáleží.
Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.
Proč kolegové? Prostě je tam nějaký code review a když lopata pořád nechápe, co je kvalita, tak má smůlu. Kolega si o tom může promluvit, ale pokud chce prasit a nevadí mu to, tak je asi ve špatném týmu. Fungování není žádný argument. Fungovat může i úplná sračka, kterou nikdo nebude chtít vylepšovat.
-
Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka.
V tomhle okamžiku jste rozbil veškerý kód, který na té speciální části závisel.
Nerozbil jsem nic.
-
Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.
To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.
WTF? Jaký objekt? Volám ty metody na rozhraní service. Nebudu snad zbytečně nějak jinak pojmenovávat service, protože mám rád jednoslovné proměnné, ne? Žádné coolSafeICanEverythingServiceWithoutProblemsTryMe :D
-
Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.
To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.
WTF? Jaký objekt? Volám ty metody na rozhraní service. Nebudu snad zbytečně nějak jinak pojmenovávat service, protože mám rád jednoslovné proměnné, ne? Žádné coolSafeICanEverythingServiceWithoutProblemsTryMe :D
V daném případě jsem použil objekty a, b, c podle předlohy. Samozřejmě jednoznakové proměnné se až na výjimky nedoporučují. Také dávám přednost jednoslovním.
-
Tady se tak nějak zapomíná na základní otázku života, vesmíru a vůbec. Je agilní vývoj dobrý? A odpověď kupodivu není 42, ale je prostě a jednoduše NE. Nechám vás chvilku přemýšlet a potom dovysvětlím zoufalcům, proč není. Na druhou stranu uznávám, že to zní pro zákazníka dobře a zákazník to chce. Proč, na to si opět zkuste odpovědět nejdřív sami. Je to jeden z důvodů, proč jsem nikdy nechtěl být programátor.
-
Agilní vývoj je přirozený. Občas lopaty zkoušely něco jiného, ale podle toho to dopadlo. Vývoj SW je jedna z nejnáročnějších disciplín vůbec a jinak než agilně nejde. Tak nám vysvětli, proč nemáš hlavu na to, abys vyvíjel?
-
Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.
Máš zkušenosti s větším živým projektem (pár tisíc tříd), který se roky iterativně posouvá dopředu dle aktuálních byznys požadavků? Pak zjistíš, že správná funkčnost kódu je jenom minimálním požadavkem. Minimálně stejně důležitým je možnost ten kód dál vyvíjet, používat, rozšiřovat. V tom je jeho hodnota. Jinak jej při každé změně budu muset zahodit a napsat to znovu. S tím souvisí základní věci - správná pojmenování všeho (a ne, opravdu na první dobrou nelze tohle dát, protože ten finální kód se od první verze zcela liší), krátké jednoduché metody (při vývoji vzniklé špagety je potřeba rozpadnout do metod - opět práce pro IDE), atd. atd. Překvapuje mě, že tohle ještě vůbec někdo v dnešní době může neznat.
Samozřejmě pokud je cílem dodat zkompilovanou binárku klientovi, vykešovat a nazdar, pak je to jedno.
Prosím odkaz na open source projekt, který má pár tisíc tříd. Používáme důsledně TDD. Změny které popisujete mohu provést snadno bez IDE. Jednu dobu jsem pracoval ve firmě, kde se řešilo pojmenování a architekura víc než funkčnost. K udržovatelnosti projektů to nevedlo. Spíš naopak.
-
https://github.com/spring-projects/spring-framework
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
-
https://github.com/openstack
-
Tady se tak nějak zapomíná na základní otázku života, vesmíru a vůbec. Je agilní vývoj dobrý? A odpověď kupodivu není 42, ale je prostě a jednoduše NE. Nechám vás chvilku přemýšlet a potom dovysvětlím zoufalcům, proč není. Na druhou stranu uznávám, že to zní pro zákazníka dobře a zákazník to chce. Proč, na to si opět zkuste odpovědět nejdřív sami. Je to jeden z důvodů, proč jsem nikdy nechtěl být programátor.
Agilní vývoj ve své podstatě vede rychleji k výslednému řešení, tedy nevidím v něm nic špatného. Otázkou však je, jak je ten agilní vývoj uchopen a zda vede k udržovatelnému kódu. Občas si totiž někdo splete "agilní vývoj" s prachobyčejným "prasením", které s agilním vývojem nemá nic společného.
-
No more planning and no more documentation.
;D
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
Nejspíš půjde vzít každý větší projekt napsaný v nějaké jazyce s třídami. Např. KDE, V8, OpenJDK, CoreCLR.
Navíc v jazycích (Kotlin, Scala, F#), kde má deklarace třídy stručnější syntax, mohou na počet řádků malé projekty mít i tisíce tříd.
-
Tady se tak nějak zapomíná na základní otázku života, vesmíru a vůbec. Je agilní vývoj dobrý? A odpověď kupodivu není 42, ale je prostě a jednoduše NE. Nechám vás chvilku přemýšlet a potom dovysvětlím zoufalcům, proč není. Na druhou stranu uznávám, že to zní pro zákazníka dobře a zákazník to chce. Proč, na to si opět zkuste odpovědět nejdřív sami. Je to jeden z důvodů, proč jsem nikdy nechtěl být programátor.
Agilní vývoj ve své podstatě vede rychleji k výslednému řešení, tedy nevidím v něm nic špatného. Otázkou však je, jak je ten agilní vývoj uchopen a zda vede k udržovatelnému kódu. Občas si totiž někdo splete "agilní vývoj" s prachobyčejným "prasením", které s agilním vývojem nemá nic společného.
Ano, s prasením to dost souvisí, ono je i těžko říct, co je vlastně agilní vývoj, protože těch definic je asi tolik, kolik je vývojářů, ale ještě jsem nenašel žádnou, se kterou bych se dokázal ztotožnit. Podle mě je prvním a nejdůležitějším krokem každého projektu důkladná analýza. Bohužel, zákazník často neví co chce, nebo to nepochopí vývojář, nebo se myšlenka ztratí někde v zástupu managorů a obchodníků a agilní vývoj je potom fantastická záchrana, zní to hezky, na papíře to vypadá dobře, ale zákazník vlastně netuší, co že to chce a javamani se potom plácají navzájem po zádech, jak to dokázali pěkně přeprasit a zákazníkovi zalepit hubu. Že je z toho potom jedna dlouhá špageta, ve které se vlastně nikdo nevyzná, protože je to navíc propletený pomocí "cool IDE features", kterým se bezmezně věří (ono se musí, jinak by se nestihl termín). Optimalizace se provedou upgradem HW a na občasné pády, které jsou prohlášený za featuru, si zákazník časem zvykne. Však co, nasadíme automatický restart a tím je to pořešený.
-
ROFL
-
Podle mě je prvním a nejdůležitějším krokem každého projektu důkladná analýza. Bohužel, zákazník často neví co chce, nebo to nepochopí vývojář, nebo se myšlenka ztratí někde v zástupu managorů a obchodníků a agilní vývoj je potom fantastická záchrana, zní to hezky, na papíře to vypadá dobře, ale zákazník vlastně netuší, co že to chce a javamani se potom plácají navzájem po zádech, jak to dokázali pěkně přeprasit a zákazníkovi zalepit hubu. Že je z toho potom jedna dlouhá špageta, ve které se vlastně nikdo nevyzná, protože je to navíc propletený pomocí "cool IDE features", kterým se bezmezně věří (ono se musí, jinak by se nestihl termín). Optimalizace se provedou upgradem HW a na občasné pády, které jsou prohlášený za featuru, si zákazník časem zvykne. Však co, nasadíme automatický restart a tím je to pořešený.
Důkladná analýza pro zákazníka, který neví co chce, je velký problém. Proto uděláš zjednodušenou analýzu, podle ní nějakou alfa verzi, kterou předáš zákazníkovi ke konzultaci. Zákazník vidí, že vývoj jde kupředu a poskytne zpětnou vazbu, která poslouží jako doplněk předchozí zjednodušené analýzy a je možné udělat další iteraci. Takhle jsem dělal většinu svých úspěšných projektů a spokojenost byla na obou stranách.
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
Nejspíš půjde vzít každý větší projekt napsaný v nějaké jazyce s třídami. Např. KDE, V8, OpenJDK, CoreCLR.
Navíc v jazycích (Kotlin, Scala, F#), kde má deklarace třídy stručnější syntax, mohou na počet řádků malé projekty mít i tisíce tříd.
Tak jsem se podíval na V8. Méně než 1% zpráv commitů obsahuje slovo rename.
-
Ano, s prasením to dost souvisí, ono je i těžko říct, co je vlastně agilní vývoj, protože těch definic je asi tolik, kolik je vývojářů, ale ještě jsem nenašel žádnou, se kterou bych se dokázal ztotožnit. Podle mě je prvním a nejdůležitějším krokem každého projektu důkladná analýza. Bohužel, zákazník často neví co chce, nebo to nepochopí vývojář, nebo se myšlenka ztratí někde v zástupu managorů a obchodníků a agilní vývoj je potom fantastická záchrana, zní to hezky, na papíře to vypadá dobře, ale zákazník vlastně netuší, co že to chce a javamani se potom plácají navzájem po zádech, jak to dokázali pěkně přeprasit a zákazníkovi zalepit hubu. Že je z toho potom jedna dlouhá špageta, ve které se vlastně nikdo nevyzná, protože je to navíc propletený pomocí "cool IDE features", kterým se bezmezně věří (ono se musí, jinak by se nestihl termín). Optimalizace se provedou upgradem HW a na občasné pády, které jsou prohlášený za featuru, si zákazník časem zvykne. Však co, nasadíme automatický restart a tím je to pořešený.
Takze - teorii neznas. Praxi neznas. Sam rikas, ze programator nejsi. Proc teda remcas o vecech, o kterych mas nanejvys matne tuseni?
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
Nejspíš půjde vzít každý větší projekt napsaný v nějaké jazyce s třídami. Např. KDE, V8, OpenJDK, CoreCLR.
Navíc v jazycích (Kotlin, Scala, F#), kde má deklarace třídy stručnější syntax, mohou na počet řádků malé projekty mít i tisíce tříd.
Tak jsem se podíval na V8. Méně než 1% zpráv commitů obsahuje slovo rename.
Protože se to dává do refactoringu?
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
Nejspíš půjde vzít každý větší projekt napsaný v nějaké jazyce s třídami. Např. KDE, V8, OpenJDK, CoreCLR.
Navíc v jazycích (Kotlin, Scala, F#), kde má deklarace třídy stručnější syntax, mohou na počet řádků malé projekty mít i tisíce tříd.
Tak jsem se podíval na V8. Méně než 1% zpráv commitů obsahuje slovo rename.
Protože se to dává do refactoringu?
Slovo refactoring jich obsahuje ješně méně.
-
Takze - teorii neznas. Praxi neznas. Sam rikas, ze programator nejsi. Proc teda remcas o vecech, o kterych mas nanejvys matne tuseni?
Protože mě baví, jak se tu profesionálové chlubí, že prasení je jejich styl práce, který považují za dokonalý. Mimochodem, argumentačně jsi momentálně někde na javamanově úrovni. Klidně si to nechám od profíka vysvětlit.
-
Slovo refactoring jich obsahuje ješně méně.
Tak jsou to lopaty a vybral sis špatný projekt.
-
Neměl bys projekt který i něco užitečného dělá? Tohle je jen onanie SW architektů.
Nejspíš půjde vzít každý větší projekt napsaný v nějaké jazyce s třídami. Např. KDE, V8, OpenJDK, CoreCLR.
Navíc v jazycích (Kotlin, Scala, F#), kde má deklarace třídy stručnější syntax, mohou na počet řádků malé projekty mít i tisíce tříd.
Tak jsem se podíval na V8. Méně než 1% zpráv commitů obsahuje slovo rename.
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
-
Důkladná analýza pro zákazníka, který neví co chce, je velký problém. Proto uděláš zjednodušenou analýzu, podle ní nějakou alfa verzi, kterou předáš zákazníkovi ke konzultaci. Zákazník vidí, že vývoj jde kupředu a poskytne zpětnou vazbu, která poslouží jako doplněk předchozí zjednodušené analýzy a je možné udělat další iteraci. Takhle jsem dělal většinu svých úspěšných projektů a spokojenost byla na obou stranách.
Já vím, jak to je. Zákazník neví co chce, vývojáři neví, co zákazník chce a podle toho to vypadá. Dá se to zvládnout slušně, ale stojí to čas a čas jsou peníze. Já si narozdíl od většiny zde přítomných můžu dovolit věnovat svým projektům spousty času a proto se snažím, když už něco dělám, to dělat pořádně. Nevyčítám nic ani těm, kteří to prostě kvůli termínům a rozpočtům prasí - chápu je a dělal bych to stejně, kdybych musel. Ale ať alespoň neprohlašují prasení za standard a prasící postupy a nástroje za fantastické a nepostradatelné. Úplně z téhle diskuze tuším ty skvělé názvy tříd, metod, proměnných a kdoví, čeho ještě - a,b,c,abc,xx,zzz,asdf a podobně. To perfektně vystihuje závislost na prasofunkcích.
-
Takze - teorii neznas. Praxi neznas. Sam rikas, ze programator nejsi. Proc teda remcas o vecech, o kterych mas nanejvys matne tuseni?
Protože mě baví, jak se tu profesionálové chlubí, že prasení je jejich styl práce, který považují za dokonalý. Mimochodem, argumentačně jsi momentálně někde na javamanově úrovni. Klidně si to nechám od profíka vysvětlit.
Teorii neznas - rikal jsi, ze regexpy staci
Praxi neznas - to, co popisujes, neni agilni vyvoj. (a pokud ti to nekdo jako agilni vyvoj prodal, tak ti lhal)
Programator nejsi - to jsi rikal.
Definatoricky sis rekl, ze agile = praseni (bez toho, aby sis ocividne zjistil, co to doopravdy je). Kdyz se tu bavime o jedne z metod zlepsovani kodu, tak navrhujes aburni postupy, jak ji dosahnout.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
-
Důkladná analýza pro zákazníka, který neví co chce, je velký problém. Proto uděláš zjednodušenou analýzu, podle ní nějakou alfa verzi, kterou předáš zákazníkovi ke konzultaci. Zákazník vidí, že vývoj jde kupředu a poskytne zpětnou vazbu, která poslouží jako doplněk předchozí zjednodušené analýzy a je možné udělat další iteraci. Takhle jsem dělal většinu svých úspěšných projektů a spokojenost byla na obou stranách.
Já vím, jak to je. Zákazník neví co chce, vývojáři neví, co zákazník chce a podle toho to vypadá. Dá se to zvládnout slušně, ale stojí to čas a čas jsou peníze. Já si narozdíl od většiny zde přítomných můžu dovolit věnovat svým projektům spousty času a proto se snažím, když už něco dělám, to dělat pořádně. Nevyčítám nic ani těm, kteří to prostě kvůli termínům a rozpočtům prasí - chápu je a dělal bych to stejně, kdybych musel. Ale ať alespoň neprohlašují prasení za standard a prasící postupy a nástroje za fantastické a nepostradatelné. Úplně z téhle diskuze tuším ty skvělé názvy tříd, metod, proměnných a kdoví, čeho ještě - a,b,c,abc,xx,zzz,asdf a podobně. To perfektně vystihuje závislost na prasofunkcích.
Jasne. A trebas strejda Bob bude prase nejvetsi.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Ne.
-
Teorii neznas - rikal jsi, ze regexpy staci
Praxi neznas - to, co popisujes, neni agilni vyvoj. (a pokud ti to nekdo jako agilni vyvoj prodal, tak ti lhal)
Programator nejsi - to jsi rikal.
Definatoricky sis rekl, ze agile = praseni (bez toho, aby sis ocividne zjistil, co to doopravdy je). Kdyz se tu bavime o jedne z metod zlepsovani kodu, tak navrhujes aburni postupy, jak ji dosahnout.
Takže mi prosím napiš asi miliontou definici agilního vývoje, ať si můžeme navzájem poměřit přirození a neměříme si každej něco jinýho. Ke zbytku se vyjádřím následně.
-
Takže mi prosím napiš asi miliontou definici agilního vývoje, ať si můžeme navzájem poměřit přirození a neměříme si každej něco jinýho. Ke zbytku se vyjádřím následně.
Vcelku IMO staci wikipedicka definice z prvniho odstavce:
"Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change."
-
Co se tyka "praseni", tak je spis v agile udelat malo ale rychle, lepe a predpovidatelne.
-
Jasne. A trebas strejda Bob bude prase nejvetsi.
Proč označuješ strejdu Boba za prase? Co ti provedl?
-
Jasne. A trebas strejda Bob bude prase nejvetsi.
Proč označuješ strejdu Boba za prase? Co ti provedl?
Sarkasmus.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.
-
Co se tyka "praseni", tak je spis v agile udelat malo ale rychle, lepe a predpovidatelne.
Dobrá, vyjdeme z této relativně obecné definice, ke které si každej přidá zbytek jakej chce, ale na tomto se celkem shodneme a většina dalších lidí taky. Já tvrdím, že agilní vývoj je možný, ale nad solidním jádrem aplikace, který nemusím měnit kvůli každé prkotině a které rozhodně nemůže být výsledkem agilního vývoje, ale kvalitní analýzy, důkladných testů a jisté intuice zajišťující budoucí škálovatelnost potřebným směrem. Pokud má někdo potřebu spouštět dříve zmíněné úpravy nad celým projektem, nebo dokonce několika projekty, potom je to přesně to prasení, o kterým tu mluvím a výsledek nemůže být jiný, než zprasený.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.
Tím ovšem odpadá dříve kritizovaná potřeba globálních úprav, takže se bavíme jeden o voze a druhej o koze.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Ne.
? Ne? Opravdu? No tak ne... ale co ne? Ne proto, že jsem to psal já, nebo není přejmenování napříč projektem prkotina, nebo bys nedal tak blbej comment, nebo není spolupráce radost? Nebo prostě ne?
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.
Tím ovšem odpadá dříve kritizovaná potřeba globálních úprav, takže se bavíme jeden o voze a druhej o koze.
Proč myslíte, že odpadá? Když má featura tisíce řádků (např. se na ní pracuje několik let), tak ta přejmenování mohou být poměrně složitá.
-
Jasne. A trebas strejda Bob bude prase nejvetsi.
Proč označuješ strejdu Boba za prase? Co ti provedl?
Sarkasmus.
Už vím, co ti provedl. Zakázal ti používat gettery a settery:
Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?
...
The worst option is to blithely add getters and setters.
...
... have private variables manipulated by getters and setters. The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit.
-
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.
Dustin mluvil o stovkách commitů od každého vývojáře.
-
Proč myslíte, že odpadá? Když má featura tisíce řádků (např. se na ní pracuje několik let), tak ta přejmenování mohou být poměrně složitá.
Takže celé roky pracuješ nad svým forkem? Nebo to commituješ do develu, kterej se nedostane do mainu a nemáš potřebu nikomu sdělit, co děláš? Nebo to commituješ do mainu a opět v commitech neříkáš, co děláš a kód se nepoužívá? Nebo jakým způsobem se stane, že nikomu nesdělíš, co provádíš se svou roky vyvíjenou fičurou?
-
Myslíš tohle?
https://github.com/python-rope/rope/blob/master/docs/overview.rst#move-method-refactoring
Ne, myslím tohle:
class Child(object):
def a_method(self):
pass
def b_method(self):
pass
child1 = Child()
child1.a_method()
child2 = Child()
child2.a_method()
child2.b_method()
Po refaktorování:
class Parent(object):
def a_method(self):
pass
class Child(Parent):
def b_method(self):
pass
parent1 = Parent()
parent1.a_method()
child2 = Child()
child2.a_method()
child2.b_method()
Dosud jsme se bavili o prostém přejmenování funkce. K tomu stačí jednoduší nástroje.
O pouhém přejmenování se asi baví jenom ti, kteří tvrdí, že si vystačí s regulárními výrazy. A navíc tu pořád nikdo neukázal, jak bude pomocí regulárního výrazu automaticky přejmenovávat metodu, když stejně pojmenovanou metodu bude mít v desítkách dalších tříd.
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?
Pro tohle bych si mohl napsat funkci pomocí jedi a rope api. Ale nedovedu si představit situaci, kdy bych to potřeboval. Kdybych přejmenoval všechno na parent, tak mi flycheck červeně podtrhne to použití b_method. Chyba tedy nehrozí.
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
Výhoda to není.
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
Jaká je výhoda toho, si něco nechat programovat na míru, když absolutní většina věcí už se dá řešit existujícími nástroji?
-
Proč myslíte, že odpadá? Když má featura tisíce řádků (např. se na ní pracuje několik let), tak ta přejmenování mohou být poměrně složitá.
Takže celé roky pracuješ nad svým forkem? Nebo to commituješ do develu, kterej se nedostane do mainu a nemáš potřebu nikomu sdělit, co děláš? Nebo to commituješ do mainu a opět v commitech neříkáš, co děláš a kód se nepoužívá? Nebo jakým způsobem se stane, že nikomu nesdělíš, co provádíš se svou roky vyvíjenou fičurou?
Kód se třeba roky vyvíjí v rámci pull requestu mimo hlavní větev - komunita může dělat review a až je vše připraveno, squashne se kód do několika desítek commitů.
To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.
Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.
Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.
Dustin mluvil o stovkách commitů od každého vývojáře.
Například pracovní verze https://github.com/ocaml/ocaml/pull/132 měla přes 1200 commitů, tyto commity se však nemergovaly - místo toho se vytvořily jiné, kterých bylo mnohem méně.
-
Sorry, v předchozím příspěvku jsem nechtěl citovat gl - celá odpověď patří Tuxikovi.
-
Takže co nejde do mainu se nekomentuje? Komunita může koukat, ale sama si musí dohledat co se změnilo a pomocí křišťálové koule odhadovat proč? Není to dost neefektivní?
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
Výhoda to není.
Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.
-
Uznávám, že PyCharm toho asi umí víc, ale takovouhle funkčnost by mne nenapadlo hledat. Celkově dědičnost používám velmi zřídka, a smysl téhle úpravy mi uniká. Může tam být případ, kdy bych chtěl použít Child, ale nepoužiji b_method, tak se mi to přejmenuje.
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
Výhoda to není.
Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.
Obávám se ale, že kvůli tomu ani ve svém oblíbeném prostředí nebude psát ten skript a raději kód nějak naprasí bez refaktoringu. Protože to je s jeho oblíbenými nástroji nejjednodušší řešení.
Pořád jde ale o to, co kdo píše. Pokud někdo píše nějaké algoritmy nebo struktury, typicky mění malou část kódu a důležité je pro něj hlavně psaní a editace kódu. Pokud zná Vim nebo Emacs, bude v nich efektivnější než s IDE. Pokud někdo potřebuje propojit spoustu komponent do jednoho celku (typická Java aplikace), potřebuje naopak pořádné IDE, protože nepotřebuje detailně znát nějaký kód, ale naopak potřebuje mít přehled o aplikaci na vyšší úrovni.
-
Pro tohle bych si mohl napsat funkci
Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?
Výhoda to není.
Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.
Obávám se ale, že kvůli tomu ani ve svém oblíbeném prostředí nebude psát ten skript a raději kód nějak naprasí bez refaktoringu. Protože to je s jeho oblíbenými nástroji nejjednodušší řešení.
Pořád jde ale o to, co kdo píše. Pokud někdo píše nějaké algoritmy nebo struktury, typicky mění malou část kódu a důležité je pro něj hlavně psaní a editace kódu. Pokud zná Vim nebo Emacs, bude v nich efektivnější než s IDE. Pokud někdo potřebuje propojit spoustu komponent do jednoho celku (typická Java aplikace), potřebuje naopak pořádné IDE, protože nepotřebuje detailně znát nějaký kód, ale naopak potřebuje mít přehled o aplikaci na vyšší úrovni.
V tomhle případě to přejmenuju všechno a kde bude pylint řvát, vrátím to zpět. Triviální úprava. Budu ji nejspíš dělat jen jednou za život. Není třeba k tomu mít speciální funkci.
-
Takže co nejde do mainu se nekomentuje? Komunita může koukat, ale sama si musí dohledat co se změnilo a pomocí křišťálové koule odhadovat proč? Není to dost neefektivní?
Neverzuješ ty tím novým adresářem na sdíleném disku? U složitějšího třeba Git flow je to úplně normální. Nikoho nezajímá, co sis někde prasil, když si jen přidával něco konkrétního.
-
Pořád jde ale o to, co kdo píše. Pokud někdo píše nějaké algoritmy nebo struktury, typicky mění malou část kódu a důležité je pro něj hlavně psaní a editace kódu. Pokud zná Vim nebo Emacs, bude v nich efektivnější než s IDE. Pokud někdo potřebuje propojit spoustu komponent do jednoho celku (typická Java aplikace), potřebuje naopak pořádné IDE, protože nepotřebuje detailně znát nějaký kód, ale naopak potřebuje mít přehled o aplikaci na vyšší úrovni.
Tak jsem si nainstaloval PyCharm a nemohu přijít na postup jak provést to refaktorování o kterém jsi psal výše. Na rozdíl od Emacsu to vůbec neupozorňuje na použití neexistujících metod.
-
Asi špatnej jazyk :D A teď už víš, proč se v něm nic velkého nedělá.
-
Asi špatnej jazyk :D A teď už víš, proč se v něm nic velkého nedělá.
Špatné IDE.
-
Tak jsem si nainstaloval PyCharm a nemohu přijít na postup jak provést to refaktorování o kterém jsi psal výše. Na rozdíl od Emacsu to vůbec neupozorňuje na použití neexistujících metod.
V IntelliJ Idea se to jmenuje Extract - Interface nebo Superclass. Netuším, zda stejný refaktoring mají i pro Python.
-
Tak jsem si nainstaloval PyCharm a nemohu přijít na postup jak provést to refaktorování o kterém jsi psal výše. Na rozdíl od Emacsu to vůbec neupozorňuje na použití neexistujících metod.
V IntelliJ Idea se to jmenuje Extract - Interface nebo Superclass. Netuším, zda stejný refaktoring mají i pro Python.
Extract superclass provede tohle:
class Parent(object):
def a_method(self):
pass
class Child(Parent):
def b_method(self):
pass
child1 = Child()
child1.a_method()
child2 = Child()
child2.a_method()
child2.b_method()
u použití nic nezmění.
-
Na první dojem je PyCharm jen pozlacená sračka. Zkusím to pár dnů používat. Třeba se mýlím.
-
OMG, sračka je Python. PyCharm by to samozřejmě všechno uměl, kdyby to jazyk podporoval. Je to normální Idea, jen trochu osekaná.
Až se naučíš trochu programovat, můžeš přejít na plnotučné jazyky jako Java.
-
Extract superclass provede tohle:
[...]
u použití nic nezmění.
Idea tohle s Javou udělá v prvním kroku, ale hned se zeptá, zda má nahradit použití třídy potomka třídou předka tam, kde je to možné, a po schválení provede i ten druhý refaktoring. Možná to IDE pro jiné jazyky neumí - přeci jen Idea je jejich vlajková loď a Java je pro IDE snazší na "pochopení", takže se dá předpokládat, že pro jiné jazyky ten refaktoring nebude tak promakaný. A taky je možné, že v Pythonu takový refaktoring potkáte méně často, než v Javě - přeci jen průměrný projekt v Pythonu asi bude o dost menší, než průměrný projekt v Javě.
-
... A taky je možné, že v Pythonu takový refaktoring potkáte méně často, než v Javě - přeci jen průměrný projekt v Pythonu asi bude o dost menší, než průměrný projekt v Javě.
Souhlas. Když stejný projekt uděláš v Pythonu a v Javě, tak ten v Pythonu bude zajisté o dost menší.
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
-
Skriptovací jazyky na velké projekty nebrat.
Zrovna v tomhle nemá Java Pythonu dohromady co vyčítat.
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
nejsem zastance pythonu, vlastne spis naopak, ale:
http://stackoverflow.com/questions/35753/is-python-good-for-big-software-projects-not-web-based#259591
-
Kašlete na to, konečně se vyjasnilo a ještě jsou k vidění Perseidy. Už sice nejsou v maximu, ale tak 20 za hodinu to dává. Spacák na zahrádku, dobrej tabáček, fajnová lahvinka, pěkná podívaná :)
-
Kašlete na to, konečně se vyjasnilo a ještě jsou k vidění Perseidy. Už sice nejsou v maximu, ale tak 20 za hodinu to dává. Spacák na zahrádku, dobrej tabáček, fajnová lahvinka, pěkná podívaná :)
Maximum teprve bude příští týden ve čtvrtek.
-
Kašlete na to, konečně se vyjasnilo a ještě jsou k vidění Perseidy. Už sice nejsou v maximu, ale tak 20 za hodinu to dává. Spacák na zahrádku, dobrej tabáček, fajnová lahvinka, pěkná podívaná :)
Maximum teprve bude příští týden ve čtvrtek.
sakra.... chyba ve výpočtu? Čtvrtek si pamatuju, ale v datumu sem se asi sekl :D Nevadí, Perseidy lítají tak týden před a týden po a až teď to stojí za to :)
edit: fakt jo :D Nevadí, jestli bude hezky, zalehnu s dcerkou a vynechám tabáček a lahvinku no :D stejně jí slibuju stan už 3 týdny :)
-
Já bych místo dcerky radši vzal nějakou "dcérečku"... :P
-
Já bych místo dcerky radši vzal nějakou "dcérečku"... :P
Mno jo, na hvězdičky se ženský chytaly už na táborech, ale s manželkou to nehne. Ta se raději vyspí, než koukat do rána doblba :D
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
-
Určitě. Proto se Python všude používá :D Vůbec to není chyba jazyka, že nepodporuje velké aplikace. Může za to zlé IDE, které při dobrých jazycích funguje bez problémů.
-
Určitě. Proto se Python všude používá :D Vůbec to není chyba jazyka, že nepodporuje velké aplikace. Může za to zlé IDE, které při dobrých jazycích funguje bez problémů.
Jak by měl jazyk podporovat velké aplikace? Co je to za blbost? Systém modulů je v Pythonu lepší než v Javě, kde žádný není. Statická analýza pythonovského kódu většinou není problém. Nefunguje to jen v málo případech. To stejné platí pro Javu. Tam to funguje také jen pokud nepoužiješ reflexi.
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Nebylo tu uz nekolikrat receno, ze z principu NE?
Kvuli dynamickemu typovani nejsi obene schopen poznat v compiletime ktere jmeno patri k cemu.
-
Určitě. Proto se Python všude používá :D Vůbec to není chyba jazyka, že nepodporuje velké aplikace. Může za to zlé IDE, které při dobrých jazycích funguje bez problémů.
Jak by měl jazyk podporovat velké aplikace? Co je to za blbost? Systém modulů je v Pythonu lepší než v Javě, kde žádný není. Statická analýza pythonovského kódu většinou není problém. Nefunguje to jen v málo případech. To stejné platí pro Javu. Tam to funguje také jen pokud nepoužiješ reflexi.
Tak si někdy zkus Javu a uvidíš, co znamená podpora pro obrovské aplikace. Ze všech stran to na tebe křičí, že je připravená na to největší.
Statická analýza není problém? Si děláš srandu? Problém určitě není, otázkou ale je, k čemu ti bude :D
Proč bys v Javě používal reflexi? Není tak trochu pomalá a neničí ti architekturu?
-
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Má to jediný háček - to špatné IDE od IntelliJ je v současnosti to nejlepší, co je k dostání. Zatímco to vaše ještě lepší IDE, pomocí kterého to půjde snadno, zatím neexistuje. (Vím, že jste psal o vhodných nástrojích a já píšu o IDE, ale když se ty nástroje mají používat snadno, musí být samozřejmě použitelné z jednoho místa jednotným způsobem, nebo-li to musí být integrované ve vývojovém prostředí, nebo-li IDE. Jestli to IDE vytvoříte tak, že z vimu budete spouštět nějaké externí nástroje, na tom nezáleží - důležité je, že to má vývojář vše na jednom místě a ovládá to stejným způsobem.)
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Nebylo tu uz nekolikrat receno, ze z principu NE?
Kvuli dynamickemu typovani nejsi obene schopen poznat v compiletime ktere jmeno patri k cemu.
A to něčemu vadí? Už několikrát zde bylo řečeno, že pokud se někdo pokouší psát v Pythonu stejně jako v Javě, tak to obvykle dopadne špatně. V Pythonu se prostě programuje zcela jiným stylem.
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Nebylo tu uz nekolikrat receno, ze z principu NE?
Kvuli dynamickemu typovani nejsi obene schopen poznat v compiletime ktere jmeno patri k cemu.
Pokud ten jazyk používám jako statický, tak to jde.
(https://postimg.org/image/o5b9perlz/)
(https://postimg.org/image/sjix9u135/)
-
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Má to jediný háček - to špatné IDE od IntelliJ je v současnosti to nejlepší, co je k dostání. Zatímco to vaše ještě lepší IDE, pomocí kterého to půjde snadno, zatím neexistuje. (Vím, že jste psal o vhodných nástrojích a já píšu o IDE, ale když se ty nástroje mají používat snadno, musí být samozřejmě použitelné z jednoho místa jednotným způsobem, nebo-li to musí být integrované ve vývojovém prostředí, nebo-li IDE. Jestli to IDE vytvoříte tak, že z vimu budete spouštět nějaké externí nástroje, na tom nezáleží - důležité je, že to má vývojář vše na jednom místě a ovládá to stejným způsobem.)
Tím háčkem je tedy FUD.
-
Ale zase nepůjde refaktorovat a opravovat. Takže pokud jsi nějaký čas ušetřil, což není jisté, tak jsi ho po nějaké době ztratil tak desetinásobek. Skriptovací jazyky na velké projekty nebrat.
Nepůjde to pomocí špatného IDE od IntelliJ. Pomocí vhodných nástrojů to půjde snadno.
Nebylo tu uz nekolikrat receno, ze z principu NE?
Kvuli dynamickemu typovani nejsi obene schopen poznat v compiletime ktere jmeno patri k cemu.
Pokud ten jazyk používám jako statický, tak to jde.
Chtěl jsem vložit obrázky.
https://postimg.org/image/o5b9perlz/
https://postimg.org/image/sjix9u135/
-
(https://s7.postimg.org/o5b9perlz/Screenshot_emacs.png) (https://postimg.org/image/o5b9perlz/)
(https://s8.postimg.org/sjix9u135/Screenshot_from_2016_08_07_15_55_38.png) (https://postimg.org/image/sjix9u135/)
-
Takže jako argument metody můžeš poslat jen některé typy? K čemu pak používat skriptovací Python?
-
Takže jako argument metody můžeš poslat jen některé typy? K čemu pak používat skriptovací Python?
Můžu používat co chci. Když to vypadá podezřele, tak mne IDE upozorní.
-
Můžeš mi ukázat ten obrázek s tím? Když chceš nějakou metodu volat, tak typ poznáš podle čeho?
-
Můžeš mi ukázat ten obrázek s tím? Když chceš nějakou metodu volat, tak typ poznáš podle čeho?
Podle typové anotace. Pokud ji chci použít.
-
:D Tak to je super. On je Python skvělý, protože má všechno dynamické, ale ty z toho musíš udělat statické, aby to šlo použít. Plus nepodpora pro velké projekty a vyjdem nám z toho luxusní jazyk :D
-
:D Tak to je super. On je Python skvělý, protože má všechno dynamické, ale ty z toho musíš udělat statické, aby to šlo použít. Plus nepodpora pro velké projekty a vyjdem nám z toho luxusní jazyk :D
Fígl je v tom, že z toho statické dělat nemusíš.
Nepodpora pro velké projekty je opět jen FUD.
-
Jen pak v tom nejde dělat, no. Si nevybereš.
Takže co v Pythonu je určené pro velké projekty? Jaký FUD? Java tenhle skriptovací paskvil strčí do kapsy, i když neříkám, že je dokonalá. Jen nic lepšího nenajdeš.
-
Jen pak v tom nejde dělat, no. Si nevybereš.
Takže co v Pythonu je určené pro velké projekty? Jaký FUD? Java tenhle skriptovací paskvil strčí do kapsy, i když neříkám, že je dokonalá. Jen nic lepšího nenajdeš.
Python je stejně skriptovací, jako třeba Java. Tvůj FUD spočívá v tom, že o Pythonu nic nevíš a jen o něm šíříš bludy.
-
Tak mi prosím ukaž nějaké standardy pro vývoj obrovských aplikací. A pokud možno, rovnou mi ukaž Python knihovny, které to implementují. Abych jako měl všechno po ruce, když se do toho pustím a nemusel lovit někde v bahně. Jaké design patterny třeba v Pythonu můžu použít? Aha, ono jich tam moc nejde, protože přece nejsou potřeba, co? Kde je tam vlastně rozhraní?
-
Tak mi prosím ukaž nějaké standardy pro vývoj obrovských aplikací. A pokud možno, rovnou mi ukaž Python knihovny, které to implementují. Abych jako měl všechno po ruce, když se do toho pustím a nemusel lovit někde v bahně. Jaké design patterny třeba v Pythonu můžu použít? Aha, ono jich tam moc nejde, protože přece nejsou potřeba, co? Kde je tam vlastně rozhraní?
Víš dobře, že dělám hlavně v PHP, tedy v dalším jazyku, který nesnášíš. Přesto vím, že se v Pythonu dělají i velké aplikace. Pouze na disku nezaberou tolik místa jako javovské, proto jsou z tvého pohledu malé.
V Pythonu můžeš použít všechny běžné patterny. Některé z nich jsou přímo součástí jazyka, jiné si musíš napsat podobně jako třeba v Javě.
Rozhraní v Pythonu není. K čemu by tam bylo, když se v Pythonu používá Duck Typing? Jak bys třeba zrovna Duck Typing realizoval v Javě?
-
Jaký má smysl se hádat, zda je něco či není vhodné pro velké projekty? Ať si každý použije co chce. Je pak jeho věc, zda projekt dokáže udržet pod kontrolou a dále vyvíjet, i když už má tisíce tříd. V javě se snažíme všude vyhýbat reflexi a starý kód s reflexí předělávat na konkrétní volání (třeba zrádné wicketí PropertyModel), aby toho co nejvíc hlídat rovnou kompilátor. Samozřejmě je nutné používat rozumné IDE s naindexovanou vnitřní strukturou projektu.
Ale pokud je někdo spokojen s dynamickým typováním, je to čistě jeho věc.
-
Tak mi prosím ukaž nějaké standardy pro vývoj obrovských aplikací. A pokud možno, rovnou mi ukaž Python knihovny, které to implementují. Abych jako měl všechno po ruce, když se do toho pustím a nemusel lovit někde v bahně. Jaké design patterny třeba v Pythonu můžu použít? Aha, ono jich tam moc nejde, protože přece nejsou potřeba, co? Kde je tam vlastně rozhraní?
Víš dobře, že dělám hlavně v PHP, tedy v dalším jazyku, který nesnášíš. Přesto vím, že se v Pythonu dělají i velké aplikace. Pouze na disku nezaberou tolik místa jako javovské, proto jsou z tvého pohledu malé.
V Pythonu můžeš použít všechny běžné patterny. Některé z nich jsou přímo součástí jazyka, jiné si musíš napsat podobně jako třeba v Javě.
Rozhraní v Pythonu není. K čemu by tam bylo, když se v Pythonu používá Duck Typing? Jak bys třeba zrovna Duck Typing realizoval v Javě?
Mně PHP nevadí, je to stejná sračka jako Python, jen možná větší. Nic proti němu. Jak by se asi v Pythonu dělaly, když tam není podpora?
V Javě jsou rovnou součástí jazyka, nebo standardu, takže si jich fakt moc psát nemusíš. U Pythonu naopak nemáš často nic.
Duck typing v Javě? K čemu by mi byl, když můžu použít rozhraní? Nebo můžu použít generika, když budu potřebovat určitou flexibilitu. Duck typing je přece absolutní vopruz a nemá žádnou výhodu.
-
Duck typing je přece absolutní vopruz a nemá žádnou výhodu.
Sice souhlasim s tim, ze dynamicke typovani pro stredni a velke projekty je dost opruz - nutnost navic psat testy na typy, v podstate delat to, co se statickym typovanim lepe a rychleji udela prekladac. Podpora ve vsech IDE ve srovnani se stacickym typ. velmi uboha. Ale na male prototypovani je zase dyn. typovani dost dobre - v JS/Pythonu/Ruby muzete rychle seskladat par knihoven a mate hotovy skriptik.
-
Na skriptíky je to super, proti tomu nic nemám. Třeba místo Bashe vzít Python a udělat něco "většího".
-
Tak mi prosím ukaž nějaké standardy pro vývoj obrovských aplikací. A pokud možno, rovnou mi ukaž Python knihovny, které to implementují. Abych jako měl všechno po ruce, když se do toho pustím a nemusel lovit někde v bahně. Jaké design patterny třeba v Pythonu můžu použít? Aha, ono jich tam moc nejde, protože přece nejsou potřeba, co? Kde je tam vlastně rozhraní?
Třeba můžeš dodržovat tohle:
https://google.github.io/styleguide/pyguide.html nebo PEP8
Co by měly ty knihovny implementovat? Seznam doporučených knihoven je zde:
https://github.com/vinta/awesome-python
můžeš si vybrat co potřebuješ.
Rozhraní a většina design patternů opravdu nejsou potřeba. Pokud si rád přiděláváš práci navíc, můžeš ověřovat rozhraní například dekorátorem tříd.
Ať ti Python dobře slouží.
-
Myslím, že pořadí těch knihoven na GH vystihuje celý přístup k vývoji v Pythonu. Víc k tomu asi nemá cenu psát :D
-
Myslím, že pořadí těch knihoven na GH vystihuje celý přístup k vývoji v Pythonu. Víc k tomu asi nemá cenu psát :D
Co vystihuje pořadí ve stejném seznamu pro Javu https://github.com/akullpp/awesome-java ?
-
Že Java je královský jazyk a není pro patlaly. Já viděl ten první seznam a poblil se. U druhého jde alespoň hledat. Bordel v Pythonu ale patlalům nevadí, protože neumí ani programovat. Stejně jako ty.
-
Že Java je královský jazyk a není pro patlaly. Já viděl ten první seznam a poblil se. U druhého jde alespoň hledat. Bordel v Pythonu ale patlalům nevadí, protože neumí ani programovat. Stejně jako ty.
Chybí něco konkrétního v tom seznamu?
-
Těžko říct, když je to řazený náhodně, ale většinou jsou to patlaniny v Pythonu s mizernou dokumentací. To bych určitě chtěl používat na velkých projektech.
Prostě se tu bavíme každý o něčem jiném. Ty myslíš, že Python se dá použít na programy o 50 třídách a že je to super. OK, asi by to šlo. Mně jde o programy několik řádu větší, složitější a robustnější. Python je proti tomu hračka pro děti.
Ale když jsme chtěli, abys ukázal nějaké výhody, tak jsi akorát ukazoval nevýhody, takže to je pak těžké. Ta stránka se seznamem je super, kdyby ale byl řazený.
-
pridem z dovolenky, otvorim forum.root.cz a ten debil javaman tu stale trolluje. Hovorim si: "Ten clovek nemoze byt naozaj normalny. To musi byt chudak, ktoreho zivot je naozaj prazdny."
Nie som python programator, ale tu mas zoznam znamych aplikacii, ktore su robene v pythone.
https://en.wikipedia.org/wiki/List_of_Python_software (https://en.wikipedia.org/wiki/List_of_Python_software)
PS: Najdi si nieco, co tvoj zivot obohati, lebo akurat ukazujes, ze si vazne debil. Lutujem tvoje okolie a rodicov, ze sa musia hanbit za tak naruseneho syna.
-
A jak to souvisí, kámo? Programovat v Pythonu je jako běhat s rukama v kapsách. Jde to, ale není to ono.
-
Pisem ti to este raz:
Najdi si nieco, co tvoj zivot obohati, lebo akurat ukazujes, ze si vazne debil. Lutujem tvoje okolie a rodicov, ze sa musia hanbit za tak naruseneho syna.
-
A ty se nauč programovat, ať se můžeš příště zapojit ;)
-
Že Java je královský jazyk a není pro patlaly.
V javě máme všechno, a vůbec ji tedy za královský jazyk nepovažuju. Generika jsou napůl (chápu důvody zpětné kompatibility, ale to je nedělá dobrými), stream nepodporuje kód s checked výjimkami, v parallel se do vláken nepřenese sešna - threadlocal (důvody chápu, ale přesto je to opruz), jsou implementované jedním poolem vláken přes celé jvm, takže když si je jedno master vlákno zabere pro sebe, ostatní se zastaví, atd. atd.
Všechno má svoje mouchy a nic není ideální. Jo, s každou verzí něco opraví a dodělají, dostávají se do ní nové věci, neznám nic, za co bych měnil. Ale stejně jako žádný jiný jazyk není královská. A spoustu vývojářů v ní prasí úplně stejně jako v jiných jazycích a musí se to tvrdě hlídat. Jako úplně všude jinde.
-
A ty se nauč programovat, ať se můžeš příště zapojit ;)
Proč? Vy jste se přece zapojil také.
-
Že Java je královský jazyk a není pro patlaly.
V javě máme všechno, a vůbec ji tedy za královský jazyk nepovažuju. Generika jsou napůl (chápu důvody zpětné kompatibility, ale to je nedělá dobrými), stream nepodporuje kód s checked výjimkami, v parallel se do vláken nepřenese sešna - threadlocal (důvody chápu, ale přesto je to opruz), jsou implementované jedním poolem vláken přes celé jvm, takže když si je jedno master vlákno zabere pro sebe, ostatní se zastaví, atd. atd.
Všechno má svoje mouchy a nic není ideální. Jo, s každou verzí něco opraví a dodělají, dostávají se do ní nové věci, neznám nic, za co bych měnil. Ale stejně jako žádný jiný jazyk není královská. A spoustu vývojářů v ní prasí úplně stejně jako v jiných jazycích a musí se to tvrdě hlídat. Jako úplně všude jinde.
Jak napůl? Co ti nejde? Tak streamy asi divně používáš. Můžeš si udělat vlastní implementaci. Tohle tam je na vylepšení základních operací a je to dost nové. Mouchy to asi má a nebo to používáš blbě :D
Srovnání s Pythonem je dost urážka.
A ty se nauč programovat, ať se můžeš příště zapojit ;)
Proč? Vy jste se přece zapojil také.
Nechápu. Proč bych se nemohl zapojit?
-
Je nutné se zde takhle urážet?
-
Těžko říct, když je to řazený náhodně, ale většinou jsou to patlaniny v Pythonu s mizernou dokumentací...
Ta stránka se seznamem je super, kdyby ale byl řazený.
K čemu v dnešní době potřebuješ řazení seznamů?
Kromě toho si to můžeš v Javě velice snadno seřadit sám. Vždyť je to prkotina, do minuty to máš hotové.
-
Těžko říct, když je to řazený náhodně, ale většinou jsou to patlaniny v Pythonu s mizernou dokumentací...
Ta stránka se seznamem je super, kdyby ale byl řazený.
K čemu v dnešní době potřebuješ řazení seznamů?
Kromě toho si to můžeš v Javě velice snadno seřadit sám. Vždyť je to prkotina, do minuty to máš hotové.
To je přesně přístup patlalů. To máš jako testíky na pohovorech. "To máte za hodinku" :D Ne, tak se fakt v Javě nedělá.
-
Těžko říct, když je to řazený náhodně, ale většinou jsou to patlaniny v Pythonu s mizernou dokumentací...
Ta stránka se seznamem je super, kdyby ale byl řazený.
K čemu v dnešní době potřebuješ řazení seznamů?
Kromě toho si to můžeš v Javě velice snadno seřadit sám. Vždyť je to prkotina, do minuty to máš hotové.
To je přesně přístup patlalů. To máš jako testíky na pohovorech. "To máte za hodinku" :D Ne, tak se fakt v Javě nedělá.
Dobrá, dávám ti na to hodinu. Bude to stačit nebo chceš dvě?
-
V Javě se nedělají věci za hodinu. Na tohle ti stačí nějaký skriptík v Pythonu/PHP.
-
Kromě toho si to můžeš v Javě velice snadno seřadit sám. Vždyť je to prkotina, do minuty to máš hotové.
Proč bych v Javě řadil sám, když tam je Arrays.sort nebo TreeMap ? Vzhledem k celkové neefektivitě Javy tím stejně prd získám.
-
Nechápu. Proč bych se nemohl zapojit?
No psal jste, že podmínkou zapojení se je umět programovat. Přitom jste se zapojil také.
Nadáváte tu na Python, o kterém evidentně nevíte vůbec nic, a do nebe vychvalujete Javu, o které nevíte o mnoho víc. Dustin vyjmenoval několik skutečných problémů, z nichž třeba ta polovičatá implementace generik je hodně provařená, a vy vůbec netušíte, o čem je řeč.
-
V Javě se nedělají věci za hodinu. Na tohle ti stačí nějaký skriptík v Pythonu/PHP.
Kolik tedy budeš potřebovat času na to, abys to zvládl v Javě?
-
Nechápu. Proč bych se nemohl zapojit?
No psal jste, že podmínkou zapojení se je umět programovat. Přitom jste se zapojil také.
Nadáváte tu na Python, o kterém evidentně nevíte vůbec nic, a do nebe vychvalujete Javu, o které nevíte o mnoho víc. Dustin vyjmenoval několik skutečných problémů, z nichž třeba ta polovičatá implementace generik je hodně provařená, a vy vůbec netušíte, o čem je řeč.
Python je k ničemu, to se ví.
Generika nejsou dokonalá, ale co mu nejde? Polovičatá je v čem? Streamy jen neumí používat.
V Javě se nedělají věci za hodinu. Na tohle ti stačí nějaký skriptík v Pythonu/PHP.
Kolik tedy budeš potřebovat času na to, abys to zvládl v Javě?
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
-
Kromě toho si to můžeš v Javě velice snadno seřadit sám. Vždyť je to prkotina, do minuty to máš hotové.
Proč bych v Javě řadil sám, když tam je Arrays.sort nebo TreeMap ? Vzhledem k celkové neefektivitě Javy tím stejně prd získám.
Vůbec jsem mu nezakázal Arrays.sort ani TreeMap. Naopak jsem očekával, že je použije nebo se alespoň zmíní, že s nimi je to hračka.
-
Kolik tedy budeš potřebovat času na to, abys to zvládl v Javě?
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
Aha, málem bych zapomněl, že v testech pro jistotu přeskakuješ všechny levely.
-
V javě máme všechno, a vůbec ji tedy za královský jazyk nepovažuju.
Souhlasím.
Generika jsou napůl (chápu důvody zpětné kompatibility, ale to je nedělá dobrými),
Oproti C++ to má výhodu v úspoře délky kódu programu a v tom, že implementaci jde zkompilovat a strčit do knihovny. Šablony v C++ musí mít implementaci v hlavičkovém souboru.
v parallel se do vláken nepřenese sešna - threadlocal
To asi není přímo o Javě, ale o nějakém frameworku.
A spoustu vývojářů v ní prasí úplně stejně jako v jiných jazycích a musí se to tvrdě hlídat. Jako úplně všude jinde.
Všude kromě C/C++. Tam se dá velice snadno udělat neodhalitelná chyba. Java (stejně jako jiné nenativní jazyky) má kontrolu mezí pole, kontrolu castování a Garbage Collector.
-
Java (stejně jako jiné nenativní jazyky) má kontrolu mezí pole, kontrolu castování a Garbage Collector.
Tohle je velmi výhodné zejména pro začátečníky, protože to za ně Java ohlídá a případné chyby jsou poměrně dobře vidět. To předurčuje Javu pro práci i ve velkých týmech. Zkušeným programátorům naopak absence takových kontrol zas tak moc nevadí a proto jsou schopni pracovat i s dynamicky typovanými jazyky. Jsou obvykle výhodnější pro malé až jednočlenné týmy, protože rychleji (a tedy i levněji) dosáhnou požadovaných výsledků. Ve větších týmech se však taková výhodnost ztrácí.
-
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
Tak si vygůgli jak se dá seřadit HTML list.
(function sortList(ul){
var new_ul = ul.cloneNode(false);
// Add all lis to an array
var lis = [];
for(var i = ul.childNodes.length; i--;){
if(ul.childNodes[i].getElementsByTagName){
lis.push(ul.childNodes[i]);
}
}
// Sort the lis in descending order
lis.sort(function(a, b){
console.log(b.getElementsByTagName('a')[0].innerHTML);
return a.getElementsByTagName('a')[0].innerHTML.localeCompare(b.getElementsByTagName('a')[0].innerHTML);
});
// Add them into the ul in order
for(var i = 0; i < lis.length; i++)
new_ul.appendChild(lis[i]);
ul.parentNode.replaceChild(new_ul, ul);
})(document.querySelector('#readme > article > ul:nth-child(4) > li:nth-child(1) > ul'))
tohle ti ten seznam v té stránce seřadí podle abecedy.
-
Java (stejně jako jiné nenativní jazyky) má kontrolu mezí pole, kontrolu castování a Garbage Collector.
Tohle je velmi výhodné zejména pro začátečníky, protože to za ně Java ohlídá a případné chyby jsou poměrně dobře vidět. To předurčuje Javu pro práci i ve velkých týmech. Zkušeným programátorům naopak absence takových kontrol zas tak moc nevadí a proto jsou schopni pracovat i s dynamicky typovanými jazyky. Jsou obvykle výhodnější pro malé až jednočlenné týmy, protože rychleji (a tedy i levněji) dosáhnou požadovaných výsledků. Ve větších týmech se však taková výhodnost ztrácí.
Tomu se spíše říká orientace na enterprise věci, ale to ti nic neříká, tak sis to vyložil špatně po svém. To je jako Clean code.
-
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
Tak si vygůgli jak se dá seřadit HTML list.
(function sortList(ul){
var new_ul = ul.cloneNode(false);
// Add all lis to an array
var lis = [];
for(var i = ul.childNodes.length; i--;){
if(ul.childNodes[i].getElementsByTagName){
lis.push(ul.childNodes[i]);
}
}
// Sort the lis in descending order
lis.sort(function(a, b){
console.log(b.getElementsByTagName('a')[0].innerHTML);
return a.getElementsByTagName('a')[0].innerHTML.localeCompare(b.getElementsByTagName('a')[0].innerHTML);
});
// Add them into the ul in order
for(var i = 0; i < lis.length; i++)
new_ul.appendChild(lis[i]);
ul.parentNode.replaceChild(new_ul, ul);
})(document.querySelector('#readme > article > ul:nth-child(4) > li:nth-child(1) > ul'))
tohle ti ten seznam v té stránce seřadí podle abecedy.
Vidíš, jak jsi rychlý. Zítra bys mohl nastoupit jako vrchní lopata za 60 tisíc a ještě bys měl radost 8)
-
Vidíš, jak jsi rychlý. Zítra bys mohl nastoupit jako vrchní lopata za 60 tisíc a ještě bys měl radost 8)
Podobné místo už mám. Není důvod měnit.
-
A ty se nauč programovat, ať se můžeš příště zapojit ;)
no narozdiel od teba programovat viem :). alebo mas fakty, ktore hovoria o opaku?
-
Vidíš, jak jsi rychlý. Zítra bys mohl nastoupit jako vrchní lopata za 60 tisíc a ještě bys měl radost 8)
Podobné místo už mám. Není důvod měnit.
Vidíš, jak jsem tě odhadl. Kdybys nebyl lopata, tak bys mohl mít úplně jiný peníze 8) Ale tobě stačí tohle...
-
A ty se nauč programovat, ať se můžeš příště zapojit ;)
no narozdiel od teba programovat viem :). alebo mas fakty, ktore hovoria o opaku?
Není přece lopata. Nepotřebuje umět programovat.
-
Vidíš, jak jsi rychlý. Zítra bys mohl nastoupit jako vrchní lopata za 60 tisíc a ještě bys měl radost 8)
Podobné místo už mám. Není důvod měnit.
Vidíš, jak jsem tě odhadl. Kdybys nebyl lopata, tak bys mohl mít úplně jiný peníze 8) Ale tobě stačí tohle...
Stačí. Můžu používat svůj Emacs a patlat skriptíky v Pythonu. Co víc si přát.
-
Generika nejsou dokonalá, ale co mu nejde? Polovičatá je v čem? Streamy jen neumí používat.
.....
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
Z těchto dvou vyjádření mi vychází, že na javu máš lidi a sám v ní neděláš. Jinak bys věděl, o čem mluvím. Např operátor instanceof na generiku by se docela hodil, jenže kvůli implementaci jen na úrovni kompilátoru to z principu nejde. Implementace přímo v bytekódu by to umožnila, jenže pak už by nebyl zpětně kompatibilní.... Stream podporující checked výjimky si opravdu mohu implementovat sám, ale pak přicházím o očekávanou rychlost a mimo jiné i právě zde řešenou podporu v IDE. Jistě víš, že idea sama nabízí konverzi smyček na streamy, jenže když je kód z historických důvodů plný checked výjimek, jaksi smůla... Kdybys v javě dělal a byl takový borec, jak se děláš, tohle vše bys znal. A podstatně líp než já, protože já žádný borec v javě nejsem a používám jen běžné věci. A opravdu nepovažuji javu 1.8 za "je to dost nové." Víš o tom houby, jak vyplývá z blafu "Mouchy to asi má a nebo to používáš blbě".
-
Vidíš, jak jsi rychlý. Zítra bys mohl nastoupit jako vrchní lopata za 60 tisíc a ještě bys měl radost 8)
Podobné místo už mám. Není důvod měnit.
Vidíš, jak jsem tě odhadl. Kdybys nebyl lopata, tak bys mohl mít úplně jiný peníze 8) Ale tobě stačí tohle...
Stačí. Můžu používat svůj Emacs a patlat skriptíky v Pythonu. Co víc si přát.
Mně by scházel ten vývoj, ale chápu tě. To je jako teplé místečko v bance. Nikdo neruší a člověk má volnost a klid.
-
Generika nejsou dokonalá, ale co mu nejde? Polovičatá je v čem? Streamy jen neumí používat.
.....
Tyhle lopaťácký věci vůbec nedělám. Na to mám lidi.
Z těchto dvou vyjádření mi vychází, že na javu máš lidi a sám v ní neděláš. Jinak bys věděl, o čem mluvím. Např operátor instanceof na generiku by se docela hodil, jenže kvůli implementaci jen na úrovni kompilátoru to z principu nejde. Implementace přímo v bytekódu by to umožnila, jenže pak už by nebyl zpětně kompatibilní.... Stream podporující checked výjimky si opravdu mohu implementovat sám, ale pak přicházím o očekávanou rychlost a mimo jiné i právě zde řešenou podporu v IDE. Jistě víš, že idea sama nabízí konverzi smyček na streamy, jenže když je kód z historických důvodů plný checked výjimek, jaksi smůla... Kdybys v javě dělal a byl takový borec, jak se děláš, tohle vše bys znal. A podstatně líp než já, protože já žádný borec v javě nejsem a používám jen běžné věci. A opravdu nepovažuji javu 1.8 za "je to dost nové." Víš o tom houby, jak vyplývá z blafu "Mouchy to asi má a nebo to používáš blbě".
Akorát se ukazuje, že ji neumíš. Migrovat kód pomocí IDE, když tomu nerozumím, není nic moc. Instanceof chápu, ale nijak jsem ho nepotřeboval, když vím, co za typ to je a to vím. Celkově jsou generika skvělý krok kupředu, i když možná jinde umí více věcí.
Začínal jsem s Javou 1.1, takže 1.8 je opravdu trochu nová. Pokud s ní děláš dva roky a nemáš ty roky před tím, tak to chápu. Ale zase to není chyba u mě.
-
Mně by scházel ten vývoj, ale chápu tě.
Sám jsi psal, že máš na vývoj lopaty.
-
Lopaty mám na lopaťácký věci. Na vývoj je těžký sehnat lidi a dělají ho jen ti nejlepší jako já.
-
Akorát se ukazuje, že ji neumíš. Migrovat kód pomocí IDE, když tomu nerozumím, není nic moc. Instanceof chápu, ale nijak jsem ho nepotřeboval, když vím, co za typ to je a to vím.
Konkrétní typ samozřejmě nevíš, takže nemůžeš ani zavolat např. konstruktor. To by se hodilo třeba v servisech, takhle se musí dělat konkrétní potomek servisu pro každou koncovou třídu obsluhovaného DTO, abych v něm mohl zavolat new A() nebo new B() nebo new C(). Samozřejmě lze legacy kod úplně překopat a při požadavku na potomka dát servisní metody rovnou do DTO 'tak to děláme u nového kódu), ale někdy by stačilo servis jen generifikovat a doplnit do příslušné metody jenom pár instanceof. Překvapuje mě, že tohle neznáš...
Celkově jsou generika skvělý krok kupředu, i když možná jinde umí více věcí.
Generika jsou z mého pohledu samozřejmost, krok kupředu to byl před několika lety. Netypovaná pole a hlavně hasmapy byly stejné zvěrstvo jako asociativní pole v PHP.
[/quote]Začínal jsem s Javou 1.1, takže 1.8 je opravdu trochu nová. Pokud s ní děláš dva roky a nemáš ty roky před tím, tak to chápu. Ale zase to není chyba u mě.
[/quote]
První commit (z 31 tis.) máme v r. 2004 - jaká byla tehdy java? 1.8 existuje už dva roky a přechod na ni byl pro nás dost podstatný. Především kvůli lambda výrazům, které např. umožňují nahradit nebezpečné PropertyModely (tedy reflexi) ve wicketu a zároveň nezaneřádit kód spoustou balastu (např. parádní https://github.com/todvora/wicket-lambdamodel našeho exkolegy). Bohužel ostatní změny moc nevyužijeme, protože jsou dost nepoužitelné. O omezení streamu na runtime výjimky se obecně ví a na netu se na to dost nadává. Stejně tak jako nemožnost jednoduché vlastní implementace poolu vláken v parallel - klidně by jich mohlo být víc, aby se zabránilo tomu globálnímu záseku. Raději ať jádro přepíná kontexty více vláken, než jiné obslužné vlákno servletu čeká, až jiný úplně nesouvisející kód třeba v pomocném tasku dokončí svůj několikaminutový kód v parallel. Výsledek je, že se to nedá spolehlivě použít tak, jak je to hotové. Opět známý fakt, nic nového.
Pořád víc si myslím, že o javě víš velké kulové, jenom si tu taháš triko.
-
O Javě nic nevím. Mám dvě hloupé otázky.
Jistě víš, že idea sama nabízí konverzi smyček na streamy, jenže když je kód z historických důvodů plný checked výjimek, jaksi smůla...
Proč bych měl chtít konvertovat smyčku na Stream?
Generika jsou z mého pohledu samozřejmost, krok kupředu to byl před několika lety. Netypovaná pole a hlavně hasmapy byly stejné zvěrstvo jako asociativní pole v PHP.
Proč jsou asociativní pole zvěrstvo?
-
Mám dvě hloupé otázky.
Proč by měly být hloupé?
Proč bych měl chtít konvertovat smyčku na Stream?
Protože umožňuje daleko stručnější/přehlednější kód (např. http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html ). Navíc lze očekávat, že streamy budou vývojáři postupně optimalizovat a mohly by běžet rychleji než ručně napsaná smyčka. Rovněž mají potenciál snadné a "levné" paralelizace, což by byl zásadní přínos, každý nový server má minimálně dvojnásobek jader, než ten předchozí.
Proč jsou asociativní pole zvěrstvo?
Protože nejsou typovaná (nebo aspoň před řadou let nebyla, když jsme psali v PHP, dnes nevím) a často se zneužívají místo objektů. To souvisí se statickým typováním, bez kterého si nedovedu větší projekt vůbec představit...
-
Proč jsou asociativní pole zvěrstvo?
Protože nejsou typovaná (nebo aspoň před řadou let nebyla, když jsme psali v PHP, dnes nevím) a často se zneužívají místo objektů. To souvisí se statickým typováním, bez kterého si nedovedu větší projekt vůbec představit...
To nesouvisí s asociativním polem, ale dynamickým typováním v PHP. Používají se souběžně s objekty jako univerzální kolekce. Ano, je toho možné zneužívat, ale rozumný programátor to nedělá, protože objekty jsou praktičtější.
Kromě toho lze objekt snadno konvertovat na asociativní pole a naopak. Konverze je významná, protože objekt se v PHP předává odkazem, ale pole hodnotou.
-
Protože umožňuje daleko stručnější/přehlednější kód (např. http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html ). Navíc lze očekávat, že streamy budou vývojáři postupně optimalizovat a mohly by běžet rychleji než ručně napsaná smyčka. Rovněž mají potenciál snadné a "levné" paralelizace, což by byl zásadní přínos, každý nový server má minimálně dvojnásobek jader, než ten předchozí.
Volání funkce pro každý prvek dokáže Java nějak optimalizovat? V jiných jazycích bývá smyčka rychlejší.
-
Volání funkce pro každý prvek dokáže Java nějak optimalizovat? V jiných jazycích bývá smyčka rychlejší.
Na to neumím odpovědět, neznám implementační detaily v JVM ani v těch jiných jazycích. Asi p. Tišnovský by znal odpověď, ale pochybuji, že čte tuhle smutnou diskusi...
-
Protože umožňuje daleko stručnější/přehlednější kód (např. http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html ). Navíc lze očekávat, že streamy budou vývojáři postupně optimalizovat a mohly by běžet rychleji než ručně napsaná smyčka. Rovněž mají potenciál snadné a "levné" paralelizace, což by byl zásadní přínos, každý nový server má minimálně dvojnásobek jader, než ten předchozí.
Volání funkce pro každý prvek dokáže Java nějak optimalizovat? V jiných jazycích bývá smyčka rychlejší.
V PHP bývá rychlejší ten stream než smyčka. Používám ho raději, protože mi připadá elegantnější a zápis je také kratší.
-
Generika jsou z mého pohledu samozřejmost, krok kupředu to byl před několika lety. Netypovaná pole a hlavně hasmapy byly stejné zvěrstvo jako asociativní pole v PHP.
Souhlas se vším až na ta pole :-) Ta byla typovaná vždycky, asi myslíš seznamy/množiny/fronty/zásobníky?
-
Např operátor instanceof na generiku by se docela hodil, jenže kvůli implementaci jen na úrovni kompilátoru to z principu nejde.
K čemu je to dobré? Operátor instanceof nepoužívám a nějak mi nechybí.
-
Souhlas se vším až na ta pole :-) Ta byla typovaná vždycky, asi myslíš seznamy/množiny/fronty/zásobníky?
Jasně že jo, sorry :-)
-
K čemu je to dobré? Operátor instanceof nepoužívám a nějak mi nechybí.
To je tvá věc. Nicméně tady nejde přesně o instanceof, ale o možnost zjištění typu generika třídy za běhu. Což nejde, protože z generik se do runtimu nic nedostane, je to jen "pomůcka" pro kompilátor. A dost často by se to hodilo. Proto se běžně říká, že má java generika jen napůl.
-
Osobne me Java prijde jako ok jazyk, zbytecne uzvanena, ale i to se trochu lepsi. Rozhodne ma hodne much, ktere bohuzel vetsinou vychazeji z one zpetne kompatibility. Ale jak to sleduju z povzdali, tak kazda verze prinasi zatracene dobre veci, vetsinou otestovane jinymi jazyky nad JVM.
Rozhodne me prijde o rad lepsi (na stredni a velke projekty), nez vsechny ty puvodne skriptovaci dynamicke veci - PHP, Python, Ruby, JavaScript, atp.
Ted delam v praci na malem projektu v JS (15k loc), kde je zakazano psat testy, a je to hruza. Refaktoringu se bojim, radeji ho nedelam (no, co si budu namlouvat, oni by me stejne vetsi uklid neschvalili) a uz jen doklepavam bugfixy a male zmeny. Rikal jsem jim nekolikrat, ze z toho bude slepenec, kde se pri kazde druhe zmene neco rozbije a dojde se na to az za tyden. No, chteli to tak mit, maji to tak. Kdyz by se to psalo v nejakem staticky typovanem jazyce, jako treba TypeScript, Scala (ScalaJS) nebo nedejbuh Haskell (PureScript?), tak by mozna ani zadne testy potreba nebyly a zaroven by mira "rozbiti" vyrazne klesla.
K tem generikam a JVM, treba ve Scale to jde (bezi taky na JVM). Sice to neni prehnane elegantni, ale hodi se to. http://stackoverflow.com/questions/18499384/polymorphic-instantiation-in-scala-using-typetag-and-classtag
PS: O Heskellu ve startupu jsem nevadno cetl zajimavy clanek - http://baatz.io/posts/haskell-in-a-startup/. Celkem by me zajimalo, jestli je opravdu tak silna korelace mezi Haskellem a kvalitou uchazecu, kteri jim chodili (udajne byli mnohem kvalitnejsi, nez u "beznych" jazyku).
-
Ted delam v praci na malem projektu v JS (15k loc), kde je zakazano psat testy, a je to hruza.
PS: O Heskellu ve startupu jsem nevadno cetl zajimavy clanek - http://baatz.io/posts/haskell-in-a-startup/. Celkem by me zajimalo, jestli je opravdu tak silna korelace mezi Haskellem a kvalitou uchazecu, kteri jim chodili (udajne byli mnohem kvalitnejsi, nez u "beznych" jazyku).
Zakázané testy v JS musí být pořádná hrůza.
Ta korelace mezi Haskellem a kvalitou uchazečů jistě bude, protože Haskell tě naučí jiný pohled na programování, který si přeneseš i do ostatních jazyků. Totéž se dříve tvrdilo o Lispu, ale Haskell má navíc to silné typování.
-
Zeptám se jakožto JS laik - v čem může být výhodné zakázat testy?
-
K čemu je to dobré? Operátor instanceof nepoužívám a nějak mi nechybí.
To je tvá věc. Nicméně tady nejde přesně o instanceof, ale o možnost zjištění typu generika třídy za běhu. Což nejde, protože z generik se do runtimu nic nedostane, je to jen "pomůcka" pro kompilátor.
To není pravda, správně je to popsané například tady: http://tutorials.jenkov.com/java-reflection/generics.html
-
Zeptám se jakožto JS laik - v čem může být výhodné zakázat testy?
V první fázi vývoje jsou zcela zbytečné, zdržují od produktivní práce, prodlužují čas dodání, zvyšují cenu. Pokud byla aplikace slíbena rychle a levně, je výhodné je vynechat. V druhé fázi, když je aplikace produktivně nasazena a zákazník je na ní závislý, tak naopak neexistující testy pomáhají prodlužovat a tím pádem prodražovat úpravy, pro zákazníka bude těžké předat projekt někomu jinému a firma dodávající řešení může zákazníka efektivně ždímat.
-
To není pravda, správně je to popsané například tady: http://tutorials.jenkov.com/java-reflection/generics.html
Díky za upřesnění, tohle jsem nevěděl. I tak je to zjištění dost komplikované (= nefektivní) a netýká se přímo třídy (což je to, co mě zajímá), ale jejího fieldu/metody. Ale jo, dát se to nahackovat... Jenže to je přesně to, čemu se člověk chce vyhnout :-( Upřímně to už raději udělám toho potomka parametrizované třídy pro jeden konkrétní typ a zavolám si v ní jeho konstruktor natvrdo...
-
Zeptám se jakožto JS laik - v čem může být výhodné zakázat testy?
V některých firmách si hlídají aby programátor nenapsal ani řádku navíc, než za co je placený. Také jsem se s tím setkal. Případně zaměstnávají specialistu testera, který píše testy.
-
takovej C# ma generika uplne promakany. jina uroven nez ma java. to se musi uznat
-
Ted delam v praci na malem projektu v JS (15k loc), kde je zakazano psat testy, a je to hruza. Refaktoringu se bojim, radeji ho nedelam (no, co si budu namlouvat, oni by me stejne vetsi uklid neschvalili) a uz jen doklepavam bugfixy a male zmeny. Rikal jsem jim nekolikrat, ze z toho bude slepenec, kde se pri kazde druhe zmene neco rozbije a dojde se na to az za tyden. No, chteli to tak mit, maji to tak. Kdyz by se to psalo v nejakem staticky typovanem jazyce, jako treba TypeScript, Scala (ScalaJS) nebo nedejbuh Haskell (PureScript?), tak by mozna ani zadne testy potreba nebyly a zaroven by mira "rozbiti" vyrazne klesla.
To, že v Haskellu nejsou třeba žádné testy, je pohádka kterou vám tu v diskuzích mnohokrát vyvrátili. I vědci ověřují správnost svých úvah na konkrétních číslech. Jen vy Haskellisti dáte vše na první dobrou. Divné.
-
Ja nerikam, ze v Haskellu nejsou treba testy vubec. Jen ze je jich potreba o nekolik radu mene, nez pri stejne urovni "protestovani" napr. v tom JavaScriptu nebo jinem dynamicky typovanem jazyce. (Kdyz jsem psal o sobe, tak jsem tim myslel, ze i to minimum, ze sedi typy, by me v pripade toho JS projektu neuveritelne usetrilo cas.)
Casto se o Haskellu rika, ze pokud se to prelozi, tak to funguje spravne. A prestoze je to nadsazka, tak IMO neni tak daleko od pravdy.
-
To není pravda, správně je to popsané například tady: http://tutorials.jenkov.com/java-reflection/generics.html
Díky za upřesnění, tohle jsem nevěděl. I tak je to zjištění dost komplikované (= nefektivní)
Nechápu co vidíte komplikovaného a neefektivního na přímočarém použití reflexe.
a netýká se přímo třídy (což je to, co mě zajímá), ale jejího fieldu/metody. Ale jo, dát se to nahackovat... Jenže to je přesně to, čemu se člověk chce vyhnout :-( Upřímně to už raději udělám toho potomka parametrizované třídy pro jeden konkrétní typ a zavolám si v ní jeho konstruktor natvrdo...
Je zajímavé že přesto že evidentně vůbec nerozumíte tomu jako jsou generika v Javě implementovaná tak vám to nebrání v tom veřejně šířit bludy. Správně je to takhle a tím definitivně končím: http://www.java2s.com/Tutorials/Java/java.lang/Class/Java_Class_getGenericSuperclass_.htm
-
To je tvá věc. Nicméně tady nejde přesně o instanceof, ale o možnost zjištění typu generika třídy za běhu. Což nejde, protože z generik se do runtimu nic nedostane, je to jen "pomůcka" pro kompilátor.
To není pravda, správně je to popsané například tady: http://tutorials.jenkov.com/java-reflection/generics.html
Tohle ale řeší návratový typ metody, nikoli parametrizovaný typ, o který šlo v předchozích komentářích především. Jde o to, že nemůžete napsat například následující kód:
class Factory<T> {
public T create() {
return new T();
}
}
To se musí obcházet tím, že do té třídy předáte i instanci Class a konstruktor pak voláte pomocí reflexe.
-
Nechápu co vidíte komplikovaného a neefektivního na přímočarém použití reflexe.
V normálních jazycích s normálními generiky na to není reflexe vůbec potřeba a je to mnohem rychlejší a elegantnější:
#include <iostream>
#include <typeinfo>
#include <string>
template<typename RESULT, typename ARG1, typename ARG2>
RESULT sum(const ARG1 a, const ARG2 b)
{
std::cout << "soucet "
<< typeid(a).name() << " + "
<< typeid(b).name() << " --> "
<< typeid(RESULT).name() << std::endl;
return a + b;
}
int main()
{
auto result1 = sum<double>(1.0, 2.0f);
auto result2 = sum<std::string>(std::string("a"), std::string("b"));
return 0;
}
-
Díky, to je přesně ono. A pokud mají potomci T různé parametry konstruktoru, stačilo by pár podmínek T instanceof ... a volat konkrétní konstruktory potomků bez reflexe. Není to samozřejmě objektově čisté, ale v některých případech to má smysl.
-
Díky, to je přesně ono. A pokud mají potomci T různé parametry konstruktoru, stačilo by pár podmínek T instanceof ... a volat konkrétní konstruktory potomků bez reflexe. Není to samozřejmě objektově čisté, ale v některých případech to má smysl.
To je další věc, která nejde v Jave rozumně udělat, přitom na to stačí variadic template:
#include <memory>
#include <string>
struct Factory
{
template<typename T, typename... Args>
static std::shared_ptr<T> create(const Args&... args)
{
return std::make_shared<T>(args...);
}
};
struct A
{
A(int a) {}
};
struct B
{
B(const std::string& str, double a) {}
};
int main()
{
auto a = Factory::create<A>(1);
auto b = Factory::create<B>("hello", 2.1);
return 0;
}
-
C# rulez. Kto jeste dnes pouziva javu? :o
-
C# rulez. Kto jeste dnes pouziva javu? :o
No to je rada nad zlato... z bláta do louže :D
-
C# rulez. Kto jeste dnes pouziva javu? :o
Javaman se aspoň snaží argumentovat.
-
C# rulez. Kto jeste dnes pouziva javu? :o
Javaman se aspoň snaží argumentovat.
;D ;D ;D
Tak ten je dobrej, ten si někam napíšu.
-
Tady je argumentu hromada:
http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c (http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c)
-
Tady je argumentu hromada:
http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c (http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c)
A já nějak pořád žil v domnění, že použitý programovací jazyk se odvíjí i od toho, co potřebuji dělat...
-
Tady je argumentu hromada:
http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c (http://programmers.stackexchange.com/questions/125712/for-what-reasons-should-i-choose-c-over-java-and-c)
Neřekl bych, že to zrovna vyznívá pro C#. Properties jsou zlo. Reflexí se snažíme vystříhat, neboť znepřehledňují aplikaci. Natož v generikách. Nepochopil jsem, jakou výhodu představuje using před import. Výjimky má Java na lepší úrovni, protože pokud ji chci nechat propadnout, musím ji deklarovat. To snižuje množství chyb. Integrace s Windows je naopak škodlivá.
Jak je vidět, psal to zastánce C# a tudíž nemá smysl se tím déle zabývat.
-
no jako jasne, java nemusi byt zla. jenomze na windows bych jedoznacne doporucil C#. Proc Javu, kdyz C# je pro windows to nejlepsi.
PS: Proc jsou property zlo??? :o
-
no jako jasne, java nemusi byt zla. jenomze na windows bych jedoznacne doporucil C#. Proc Javu, kdyz C# je pro windows to nejlepsi.
PS: Proc jsou property zlo??? :o
Zde se věnujeme Windows spíše okrajově, takže je snad jasné, že ani C# tu nebude mít dost prostoru.
Property svádí programátory k tomu, aby nepracoval s objekty jako celky, ale aby manipuloval s jednotlivými atributy. Tento přístup značně omezuje práci s polymorfismem, který je jedním ze základů OOP. Navíc pokud někdo pracuje s property, umisťuje své algoritmy mimo objekt, čímž porušuje jeho zapouzdření, které je dalším pilířem OOP.
Java z důvodu čistoty jazyka property nezavedla, místo toho si však programátoři vymysleli accesory, které dokonce protlačili i do svých oblíbených IDE. Pro IDE je to jednoduchou záležitostí, pro aplikace pohromou. Sám programuji bez property, bez accesorů a výhradně s privátními atributy (kromě přepravek). Jakákoli myšlenka na vybočení z těchto kolejí je pro mne varovným signálem, že je někde chyba v návrhu.
-
jak by jste teda resili takove databinding? napr. vo Windows Presentation Foundation jsou properties pro databinding nezbytnou soucasti.
-
jak by jste teda resili takove databinding? napr. vo Windows Presentation Foundation jsou properties pro databinding nezbytnou soucasti.
Databinding řeším pomocí již uvedeného vzoru Messenger. Objekty totiž mezi sebou komunikují prostřednictvím zpráv a právě tento vzor vystihuje podstatu výměny dat mezi nimi. Properties vlastně jen vpašovávají tuto přepravku dovnitř některého z objektů a tím porušují několik dalších principů OOP.
V Javě se takový Messenger musí napsat, ale například v PHP či Pythonu je již součástí jazyka a velmi snadno se používá. Tuším, že v Haskellu tuto funkci plní některé z monád, což přispívá k eleganci toho jazyka.
Samozřejmě pokud některá systémová třída vyžaduje databinding, musím si na to napsat patřičnou proxy, se kterou pak už komunikuji standardním způsobem.
-
Čím přesně property v C# porušují OOP? Jde jen o syntaktický cukr a přeloženy jsou jako standartní get/set funkce.
-
Čím přesně property v C# porušují OOP? Jde jen o syntaktický cukr a přeloženy jsou jako standartní get/set funkce.
Property porušují zapouzdření objektu. Programátor jejich prostřednictvím manipuluje s atributy objektu mimo ten objekt místo toho, aby ty algoritmy byly zapouzdřeny uvnitř toho objektu společně s daty.
Metody get/set nejsou standardní, do OOP nepatří.
-
Čím přesně property v C# porušují OOP? Jde jen o syntaktický cukr a přeloženy jsou jako standartní get/set funkce.
Property porušují zapouzdření objektu. Programátor jejich prostřednictvím manipuluje s atributy objektu mimo ten objekt místo toho, aby ty algoritmy byly zapouzdřeny uvnitř toho objektu společně s daty.
Metody get/set nejsou standardní, do OOP nepatří.
To ale tedy není problém property, stejně tak, jak můžete využít funkce k porušení OOP můžete stejně špatně využít property. Jen si ve spoustě případů zajistíte s property "hezčí" zápis.
-
Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.
Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.
-
Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.
Podle mne by se accesory v Javascriptu vůbec neměly používat. I v Javě se dá v pohodě programovat bez nich. Třídy vychází mnohem jednodušší, mají jednodušší rozhraní a jsou i kratší. Aplikace vypadá mnohem čistěji, když nikdo kromě objektu samotného nezná jeho atributy.
Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.
Accessory jsou bohužel běžné, ale naštěstí jen v některých jazycích. V PHP je nepoužívám a domnívám se, že v Pythonu je také skoro nikdo nedělá.
-
Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.
Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.
Pokud si vzpomínám, tak immutable objekty jsou doporučovány i v Effective Java z roku 2001. Settery mohou vracet změněnou kopii objektu nebo alespoň this. Pak se dají řetězit. Takový styl se mi docela líbí v JS.
O objektech jako nosičích dat pěkně mluví Rich Hickey. Dává to smysl, ale při použití klasických objektů a metod se dá lépe využít autodoplňování. V jazycích, které nemají něco jako threading makro z Clojure mi přijde řetězení metod lepší než vnořování funkcí. Navíc v pythonu není problém sdílení metod mezi objekty různých typů.
-
Pokud jsem spravne pochopil to threading macro, tak jde o vyspelejsi formu aplikace funkci.
Jsou nejake navrhy operatoru pro forward application (casto znaceny jako |> nebo |) pro dalsi verzi JS. Existuje i nejake makro pro SweetJS, ale tam bude problem s podporou v IDE. Napr. Lodash umi urcitou formu retezeni, ale neni to uplne ono - hodnoty se musi nejdrive obalit a pak ziskavat vysledek, navic na to neni tak uplne staveny. Treba takovy Option ze Scaly (Haskelli Maybe) nevim jestli jde vubec nejak rozumne simulovat (tim myslim aby pracoval napr. s map a forEach; mozna opatchovat stavajici funkce, ale to nezni moc ciste).
V Haskellu je zajimava knihovna Flow (http://taylor.fausak.me/2015/04/09/write-more-understandable-haskell-with-flow/), kterou teda komunita pry moc dobre neprijala. Nevim, zapis me prijde hezky, ale mozna je to jen tim, ze Haskell nemam vubec zazity. V podstate elegentne resi to, co nekterym lidem (myslim i panu Prymkovi) vadi - ze cteni vyrazu v Haskellu muze byt "rozeskakane".
-
Pokud jsem spravne pochopil to threading macro, tak jde o vyspelejsi formu aplikace funkci.
Jsou nejake navrhy operatoru pro forward application (casto znaceny jako |> nebo |) pro dalsi verzi JS. Existuje i nejake makro pro SweetJS, ale tam bude problem s podporou v IDE. Napr. Lodash umi urcitou formu retezeni, ale neni to uplne ono - hodnoty se musi nejdrive obalit a pak ziskavat vysledek, navic na to neni tak uplne staveny. Treba takovy Option ze Scaly (Haskelli Maybe) nevim jestli jde vubec nejak rozumne simulovat (tim myslim aby pracoval napr. s map a forEach; mozna opatchovat stavajici funkce, ale to nezni moc ciste).
V Haskellu je zajimava knihovna Flow (http://taylor.fausak.me/2015/04/09/write-more-understandable-haskell-with-flow/), kterou teda komunita pry moc dobre neprijala. Nevim, zapis me prijde hezky, ale mozna je to jen tim, ze Haskell nemam vubec zazity. V podstate elegentne resi to, co nekterym lidem (myslim i panu Prymkovi) vadi - ze cteni vyrazu v Haskellu muze byt "rozeskakane".
existuje some-> makro. To se zastaví na první hodnotě nil. Určitě jdou v Clojure implementovat i monády a něco jako do notace z haskellu, ale nikdy jsem se s tím nesetkal.
-
...
existuje some-> makro. To se zastaví na první hodnotě nil. Určitě jdou v Clojure implementovat i monády a něco jako do notace z haskellu, ale nikdy jsem se s tím nesetkal.
To zacina byt celkem popularni - podpora preruseni retezeni na nil/null primo v jazyce. Jsem nedavno neco podobneho zahledl v Kotlinu (LiveScript ma myslim to same):
bob?.department?.head?.name
Such a chain returns null if any of the properties in it is null.
Ve Scale (a asi dost podobne i v Haskellu) se to bude resit pres Option a map/flatMap nebo lepe pres for-comprehension:
case class A(b:Option[Bool])
val optA = Some(A(Some(true)))
optA.flatMap(_.b).foreach(println) // true
for(a <- optA; x <- a.b) println(x) // true
Netusi nekdo, jak je na tom Java?
-
Netusi nekdo, jak je na tom Java?
Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.
-
Netusi nekdo, jak je na tom Java?
Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.
Použití třídy Optional je komplikovanější než zachytávání vyjímek.
-
Použití třídy Optional je komplikovanější než zachytávání vyjímek.
To zalezi. Jak si navyknes na pouziti map()a a flatMap()u, tak to zacne davat podstatne vetsi smysl.
Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.
-
Netusi nekdo, jak je na tom Java?
Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.
Použití třídy Optional je komplikovanější než zachytávání vyjímek.
Jak pro koho - možná pro líného programátora, ale rozhodně pro JVM je použití Optional efektivnější než práce s výjimkami.
-
Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.
Při použití ?. také nevím, na které dereferenci to skončilo. Vědět to nepotřebuju.
-
Jestli jsem to správně pochopil, tak flatMap s Optional funguje jen pro metody bez parametru, které vrací Optional.
-
Nebylo by jednodušší z toho streamu odfiltrovávat hodnoty null?
-
Jestli jsem to správně pochopil, tak flatMap s Optional funguje jen pro metody bez parametru, které vrací Optional.
Tak to jsi pochopil spatne. Muzes pouzit libovolnou lambdu.
o.flatMap(a -> foo.bar(1, a, 2))
Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.
Při použití ?. také nevím, na které dereferenci to skončilo. Vědět to nepotřebuju.
a?.foo(c)?.bar(d)
Kdyz tam zacnes chytat NPE a myslis si, ze tim osetrujes situace kdy a je null nebo foo vrati null... tak se pak seredne divis, ze jsi zamaskoval chybu uvnitr foo, kde je vyhozena NPE trebas protoze c je null nebo to nekdo nejak jinak pokazil...
-
Tak to jsi pochopil spatne. Muzes pouzit libovolnou lambdu.
o.flatMap(a -> foo.bar(1, a, 2))
Je to kód navíc a foo.bar stále musí vracet Optional.
-
Jestli jsem to správně pochopil, tak flatMap s Optional funguje jen pro metody bez parametru, které vrací Optional.
Jen pro metody s jedním parametrem, které vrací Optional. Co se vám na tom nezdá? Pokud máte funkci, která nevrací Optional, použijete map.
-
Tak to jsi pochopil spatne. Muzes pouzit libovolnou lambdu.
o.flatMap(a -> foo.bar(1, a, 2))
Je to kód navíc a foo.bar stále musí vracet Optional.
Hele, a jak by sis to predstavoval s otaznicky v tomhle pripade, aby to bylo kratsi?
Jinak pokud ti foo.bar nevraci Optional, tak pouzijes map()
RTFM!
-
Je to kód navíc a foo.bar stále musí vracet Optional.
Dale bych na obhajobu tohohle kodu proti chytani NPE rad poznamenal, ze to bude fungovat. Coz tvuj napad nebude.
-
Tak to jsi pochopil spatne. Muzes pouzit libovolnou lambdu.
o.flatMap(a -> foo.bar(1, a, 2))
Je to kód navíc a foo.bar stále musí vracet Optional.
Hele, a jak by sis to predstavoval s otaznicky v tomhle pripade, aby to bylo kratsi?
Jinak pokud ti foo.bar nevraci Optional, tak pouzijes map()
RTFM!
Otazníčky jsou použitelné spíš pro případ
o.flatMap(a -> a.bar(1, 2))
o.flatMap(a -> foo.bar(1, a, 2))totiž vůbec není řetězení metod. Stačilo by jednoduše vložit volání předchozí funkce na místo parametru.
-
o.flatMap(a -> foo.bar(1, a, 2))totiž vůbec není řetězení metod. Stačilo by jednoduše vložit volání předchozí funkce na místo parametru.
Chtel jsi priklad neceho slozitejsiho, tak jsi ho dostal.
A pochopitelne v tomhle pripade nestaci vlozit volani predchozi funkde na misto parametru, protoze ta
- vraci Optional, coz ten parametr neni
- neresis tim None
-
Aby to nevyznelo nejak ve spatnem - ten otaznickovy syntakticky cukr se mi celkem libi (prestozesi nejsem uplne jisty, jak by se mel v Jave chovat, protoze tam je jak null tak Optional), ale co se mi rozhodne nelibi jsou nesmyslne navrhy typu chytani NPE.
S Optional je to tak, ze si je potreba sednout, v klidu si projit dokumentaci, pripadne nejake blogposty a pak je pouzivat nejak rozumne. Ale to nejde, dokud clovek nejdriv neudela domaci ukoly a neujasni si zaklady.
-
Chtel jsi priklad neceho slozitejsiho, tak jsi ho dostal.
A pochopitelne v tomhle pripade nestaci vlozit volani predchozi funkde na misto parametru, protoze ta
- vraci Optional, coz ten parametr neni
- neresis tim None
Mluvil jsem o situaci bez použití Optional.
Celkově mi Optional přijde jako zbytečná abstrakce, která nic neusnadní. Sám jsi psal, že jde pomocí map řetězit i funkce, které Optional nevrací.
-
prestozesi nejsem uplne jisty, jak by se mel v Jave chovat, protoze tam je jak null tak Optional
Další důvod proč nepoužívat Optional.
-
prestozesi nejsem uplne jisty, jak by se mel v Jave chovat, protoze tam je jak null tak Optional
Další důvod proč nepoužívat Optional.
A na to jsi prisel jak?
-
Mluvil jsem o situaci bez použití Optional.
Celkově mi Optional přijde jako zbytečná abstrakce, která nic neusnadní. Sám jsi psal, že jde pomocí map řetězit i funkce, které Optional nevrací.
Ano, muzes pouzit map, flatMap (a dalsi metody, jeste jednou ti rikam RTFM), ktere bys uz otaznicky nenahradil.
Ne, neni to zbytecna abstrakce. Mas moznost napsat kod, ktery funguje (coz tvuj navrh reseni s catchem neni, ten je naprosto spatny) a nemusis ho prospikovat ify.
-
prestozesi nejsem uplne jisty, jak by se mel v Jave chovat, protoze tam je jak null tak Optional
Další důvod proč nepoužívat Optional.
A na to jsi prisel jak?
Už se v těchto situacích používá null případně nějaké NullObjekty. Optional nebude například fungovat v Clojure při použití some-> a some->>. Prázdný Optional se vyhodnocuje jako True.
-
Už se v těchto situacích používá null případně nějaké NullObjekty. Optional nebude například fungovat v Clojure při použití some-> a some->>. Prázdný Optional se vyhodnocuje jako True.
NullObjekty je duplicita v kodu a nutnost vytvaret zbytecne hierarchie *). Null je nejdrazsi chyba v historii pocitacu. Tohle je (pro mnoho pripadu, samozrejme ne pro uplne kazdou situaci) vyborne reseni - kompakni a bezpecne.
Ze to nejde pouzit v clojure mi zilu netrha. Pokud chteji, aby jim to fungovalo, tak at si to v clojure opravi...
*) tim nerikam, ze nemaji smysl. Nekdy jo. Ale situaci, kdy se moc nehodi, je strasne moc.
-
Už se v těchto situacích používá null případně nějaké NullObjekty. Optional nebude například fungovat v Clojure při použití some-> a some->>. Prázdný Optional se vyhodnocuje jako True.
NullObjekty je duplicita v kodu a nutnost vytvaret zbytecne hierarchie *). Null je nejdrazsi chyba v historii pocitacu. Tohle je (pro mnoho pripadu, samozrejme ne pro uplne kazdou situaci) vyborne reseni - kompakni a bezpecne.
Ze to nejde pouzit v clojure mi zilu netrha. Pokud chteji, aby jim to fungovalo, tak at si to v clojure opravi...
*) tim nerikam, ze nemaji smysl. Nekdy jo. Ale situaci, kdy se moc nehodi, je strasne moc.
V čem je to bezpečnější než null?
-
V čem je to bezpečnější než null?
Ty si delas srandu?
Ze neco muze a nemusi byt je diky Optional explicitni. Vznika jasne patterny, kde je pouziti spravne a kde je prinejmensim podezrele.
-
Ty si delas srandu?
Nedělám a pořád mi to neni jasné.
-
Ty si delas srandu?
Nedělám a pořád mi to neni jasné.
Tak jeste pomaleji:
final Foo f = foo()
f.bar()
V tomhle kodu neni bez dalsi znalosti/studia jasne, zda f muze byt null ALE f.bar() je naprosto bezny obrat a proto projde casto bez povsimnuti.
V
final Optional<Foo> f = foo()
f.get().bar()
je naprosto zrejme, ze
- foo() muze vratit "nic"
- f.get() bez kontroly je krajne podezrely obrat
Podtrzeno secteno - veci jsou zrejmejsi (ze neco muze nemit hodnotu je explicitni) a zaroven bezpecnejsi (nebezpecne operace jsou podezrele na prvni pohled jak pro lidi tak pro statickou analyzu). Navic dostavas prostredky pro bezpecnou praci s tou (ne) hodnotou, jako je map(), filter(), flatMap(). Ty jsou casto elegantnejsi nez if (f.isPresent()), protoze lepe umozni retezit operace.
Samozrejme je tady dalsi prostor pro zlepseni, z toho prikladu je trebas celkem videt, ze by Jave prospela typova inference... ale to je uz jiny pribeh.
-
Celkově mi Optional přijde jako zbytečná abstrakce, která nic neusnadní.
Základní význam Optional je v tom, že je to typově bezpečný způsob jak deklarovat, že metoda může vracet prázdnou hodnotu. Některé jazyky to mají přímo na úrovni typů (rovnou při použití nějakého typu definujete, zda může nebo nemůže být null), v Javě pro to některé nástroje definují anotaci @Nullable |opačnou k @NotNull), kterou kontroluje IDE nebo nějaký nástroj spouštěný při buildu. No a v Javě 8 to vtipně vyřešili tím, že přidali třídu Optional do standardní knihovny. Tím pádem nebylo potřeba měnit jazyk, kontrolují to už současné nástroje pro typovou kontrolu, a jako bonus se do té třídy mohly přidat metody jako map nebo flatMap, což je vlastně jen syntaktický cukr. Porovnávat to se zachycováním NPE je nesmysl, vůbec nejde o to, co je rychlejší nebo přehlednější na použití, podstatná je možnost deklarovat nullable návratový typ metody. Dá se očekávat, že nástroje provádějící statickou analýzu kódu začnou doporučovat použít Optional tam, kde metoda může vracet null.