Python - zbožňovaný lidmi?

[Kit]

Řeč byla o tom, že ani ve statickém jazyku není nutné přidávat novou metodu, kvůli novému datovému typu.

Ve statickém jazyku jsou dvě cesty: Můžeš použít společný typ, ze kterého všechny třídy dědí (např. Object) a máš stále jen jednu metodu, která se může uvnitř stát špagetou. To je ta horší cesta, která odpovídá na tvou otázku. Teď ta čistější: Prostě ty stávající metody přetížíš. Nemá smysl jim dávat různé názvy jen kvůli různým typům. Máš snad při dynamickém typování jiné možnosti?

[Reklama]

[dustin]

Jen se směju té představě, že si u velkého projektu pár programátorů něco řekne, udělaji za deset sekund změnu v tisíci souborech a tím je hotovo. Kdo tohle tvrdí, ten na reálném velkém projektu, který už z podstaty velikosti musí být řízen formálně, nikdy nic nedělal a vůbec netuší, co to obnáší.

:-) Obávám se, že jsi to ty, kdo takový projekt nikdy nespravoval. V javě to není až takový problém, je nás na to jen pár. A změny si ve své vlastní firmě opravdu  nemusím nikým nechat schvalovat.

Přejmenování třídy rozumným IDE je v javě triviální a zcela bezpečná operace, nic navíc pak testovat nemusíš, projekt je vždy poté kompilovatelný. V projektu, který negeneruje knihovny pro externí projekty mimo náš dosah, se nic rozsypat nemůže a nerozsype. Samozřejmě to předpokládá nikde v kódu nepoužívat názvy tříd v textové formě - musel bych být blázen, abych takové zvěrstvo dopustil. Pak je úplně jedno, zda se změna týká jednoho nebo tisíce souborů, vyleze z toho pořád jeden commit. Překvapuje mě, že takovou základní věc neznáš. Jenže to bude tím, že javu vůbec nepoužíváš.

[mikrom]

Já zastávám minimalistickou pozici. I kdybych vyvíjel něco v Javě, používal bych na to rád editor Vim. Otázka zní, šlo by to vůbec? Nebo je to tak špatný jazyk, že ho prakticky nelze používat bez nenažraného neefektivního bloatware, jakým bývají 'kvalitní ide', které programátory vychovávají k tomu, že potřebují pořát dokola přepracovávat kód v tisících souborech?

+1
Pravda je, ze na Python, Perl, ... C, COBOL,... staci editor. Na kompilovane jazyky je dobre este k tomu aj debugger. Len Java nevystaci s editorom. Treba k tomu tlste IDE, lebo s tak rozvlacnym a ukecanym jazykom sa neda inac pracovat. Kym som nemusel pracovat v Jave refactoring som nerobil. Nieco zmenit/premenovat v par zdrojakoch to ano, ale nikdy sa to nenazyvalo honosne "refactoring".
Dobry navrh nepotrebuje kazdu chvilu refaktorovat. Myslim si, ze tato cinnost prisla s nesvarom zvanym agile a robi sa to zamerne. Kod sa navrhne rychlo, bez rozmyslania - samozrejme nahovno a potom to stale refaktoruju a maju stale dost co robit a vykazovat. Dokola refaktorovat a tahat prachy zo zakaznika - to je dnesna strategia dodavatelskych firiem. Zabavne je ze kazdy majster sveta sa tu nafukuje ako refaktoruje tisice suborov. Tisice suborov som nikdy nemusel menit. To pracujete na nejakom softwari na riadenie galaxie, alebo preco mate tisice suborov - pre kazdy bobok hovna vyrobite class ?

Nechapem preco Javisti, ktori nevedia programovat v Pythone stale nan nadavaju.
Pred Javou som pouzival Python a ked som prechadzal na Javu bol to dost bolestivy prechod z vyssieho jazyka na ovela primitivnejsi jazyk. Vtedy bola v Jave novinka napr. foreach cyklus, ktory bol v Pythone a v Perle odjakziva.
Python je vhodny na rychle prototypovanie. Oproti Jave je ovela stucnejsi, takze napisat v nom nieco stoji zlomok usilia toho co v Jave. Preto ak ma niekto problemy, ze casto musi svoj kod refaktorovat moze zacat svoje navrhy najprv nahrubo prototypovat v Pythone a zamysliet sa nad nimi, kym ich nakodi v Jave.

[mikrom]

Ten automatický refaktoring, který ide dělá za programátora, to je podobná záležitost jako jsem uvedl výše. Čím je to levnější, tím méně člověk nad návrhem kódu přemýšlí, tím méně to umí a tím víc pak musí refaktorovat. Tak moc, že si už ani nedokáže představit, že by bylo možno vůbec programovat bez něj. Ve výsledku má špatný kód, potřebu neustále přepisovat kód a hlavně, je tím vychován programátor, který neumí dobře navrhnout kód. A s tím dobrým návrhem mu zatím žádné ide nepomůže. Ale blíží se doba AI v programování, tak to třeba nevadí. Takže fajn, taky styl práce, akorát je zajímavé, že lidé s tímto zvláštním stylem práce, protože něco neumí, si myslí, že jsou něco víc a ostatní nazývají amatéry :-).

+1
Poznam ten styl prace. Refactoring bez analyzy, rozmyslania - metoda pokus-omyl. Ak IDE po refactoringu nevyhodi cervene vykricniky a ak to pojde zbuildovat - uspech a odovzda to zakaznikovi ako improvment. A ked zakaznik pride s tym ze to jneni dobre - tak sa ide refaktorovat znovu.

[svícen]

V pátek už máš asi upito, co? Už ten Python umí rozhraní a nebo to ještě nedorazilo do dětských jazyků? A co modifikátory přístupu? Takový základy to určitě má, ne? Nebo? A věci jako BOM asi také nepotřebujete, protože jste ještě někde v roce 1991, kdy nic nebylo a dělalo se v textových editorech.

Na rychlé prototypování je právě Java a na Python se můžeš úplně vykašlat. Škoda, že o Javě píšou amatéři, kteří ani nechápou, k čemu se používá rozhraní, protože o něm nikdy nešlyšeli.

[Reklama]

[Kit]

Ten automatický refaktoring, který ide dělá za programátora, to je podobná záležitost jako jsem uvedl výše. Čím je to levnější, tím méně člověk nad návrhem kódu přemýšlí, tím méně to umí a tím víc pak musí refaktorovat. Tak moc, že si už ani nedokáže představit, že by bylo možno vůbec programovat bez něj. Ve výsledku má špatný kód, potřebu neustále přepisovat kód a hlavně, je tím vychován programátor, který neumí dobře navrhnout kód. A s tím dobrým návrhem mu zatím žádné ide nepomůže. Ale blíží se doba AI v programování, tak to třeba nevadí. Takže fajn, taky styl práce, akorát je zajímavé, že lidé s tímto zvláštním stylem práce, protože něco neumí, si myslí, že jsou něco víc a ostatní nazývají amatéry :-).

+1
Poznam ten styl prace. Refactoring bez analyzy, rozmyslania - metoda pokus-omyl. Ak IDE po refactoringu nevyhodi cervene vykricniky a ak to pojde zbuildovat - uspech a odovzda to zakaznikovi ako improvment. A ked zakaznik pride s tym ze to jneni dobre - tak sa ide refaktorovat znovu.

Tady si pod pojmem refactoring v IDE podle popisu zřejmě představují spíš přejmenování tříd a metod. Proč to dělají? Asi proto, že je to jednoduché. Ovšem transfer funkcionality mezi třídami, náhrada pole objektem, konsolidace podmínek, zavádění null objektů, likvidace příznakových proměnných, odstraňování setterů, ... - to už je trochu jinší kafe, které se moc často nevidí.

[balki]

Upratovanie v projekte je normalna zalezitost. Ak sa projekt neupratuje, casom zvykne degradovat. Povodna architektura uz nemusi vyhovovat aktualnym potrebam a robi kazdu zmenu funkcionality bolestivou. Ci sa nieco rozbilo, sa da zistit automatickymi testami a na predprodukcnom prostredi. Ak je v projekte nejaky kod, ktory nevies, co robi, preco to robi tak by si to mal zistit. Pristup "nechytat sa, ked to funguje" je nespravny, lebo potom clovek nieco robi a ani nevie co, no skratka lopatactvo deluxe. Tak ani nevies vylepsit vlastnosti, zefektivnit, dat pracu druhym koderom, skratka bieda...

Ak niekto nema na to nastroje a patle vo vim, potom je to problem ...

Škoda, že se nedovedeš zdržet urážek. Také bych tu mohl vykřikovat něco o lopatách, které bez ide, jenž programuje za ně, nedají ani ránu. Násťrojů jsem vyskoušel řadu a vždy se vrátil k vimu, když to bylo možné, dělá se mi s ním nejlíp. Jinak souhlasím, čistit a udržovat kód je nutné, má to přínos. Jen se směju té představě, že si u velkého projektu pár programátorů něco řekne, udělaji za deset sekund změnu v tisíci souborech a tím je hotovo. Kdo tohle tvrdí, ten na reálném velkém projektu, který už z podstaty velikosti musí být řízen formálně, nikdy nic nedělal a vůbec netuší, co to obnáší.

Jop, len robit upravy vo vim, nech si ho barz clovek vytuni podla tisnikovej knizky,  byva bolestive. Uz len to, ze mi IDE nadrbe tie cervene vykricniky, ako si tu niekto robil srandu, je dost pomoc.  Aspon si viem povedat "UPS", toto som nemal robit, alebo skontrolovat miesta vyskytu vykricnikov a zistit, ci ide o lahko fixnutelnu blbost, alebo sa na zmenu radsej vyserem, je napomocne. Prechadzat miesta, kde mi kompilator zarve chybu vo vim, to si radsej ukusnem ruku a zbabelo s placom a pokakany uteciem do lesov, aby som olizoval koru zo stromov. Alebo debugovat vo vim unit test, ktory mi zarve, aaah ....

To, ze IDE ludom pri programovani pomaha, v tom nevidim problem. Pri programovani sa pouzivaju rozne barlicky, IDE, ake je neinvazivne (Tj nenadrbe svoje custom hacky do kodu), tam nevidim problem.

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

[Kit]

Jop, len robit upravy vo vim, nech si ho barz clovek vytuni podla tisnikovej knizky,  byva bolestive. Uz len to, ze mi IDE nadrbe tie cervene vykricniky, ako si tu niekto robil srandu, je dost pomoc.  Aspon si viem povedat "UPS", toto som nemal robit, alebo skontrolovat miesta vyskytu vykricnikov a zistit, ci ide o lahko fixnutelnu blbost, alebo sa na zmenu radsej vyserem, je napomocne. Prechadzat miesta, kde mi kompilator zarve chybu vo vim, to si radsej ukusnem ruku a zbabelo s placom a pokakany uteciem do lesov, aby som olizoval koru zo stromov. Alebo debugovat vo vim unit test, ktory mi zarve, aaah ....

Vim si v průběhu času vytuní každý podle svých potřeb a konfiguraci si přenese mezi všemi používanými instancemi.

K čemu jsou dobré ty červené vykřičníky v IDE? Vim mi je nedělá a nedělá je ani IDE, které otevře soubor po editaci ve Vimu. Po kompilaci skočí Vim na místo, kde byla hlášena chyba. V čem je problém?

To, ze IDE ludom pri programovani pomaha, v tom nevidim problem. Pri programovani sa pouzivaju rozne barlicky, IDE, ake je neinvazivne (Tj nenadrbe svoje custom hacky do kodu), tam nevidim problem.

Vidím problém v tom že IDE lidem při programování pomáhá vytvářet junkcode, ve kterém nepomůže najít jiné chyby, než syntaktické.

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

Měnit názvy veřejných metod, které se už používají, není refaktoring, ale zvrhlost.

[balki]

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

Měnit názvy veřejných metod, které se už používají, není refaktoring, ale zvrhlost.

Ak sa zle volaju, nevidim v tom problem.

[balki]

Jop, len robit upravy vo vim, nech si ho barz clovek vytuni podla tisnikovej knizky,  byva bolestive. Uz len to, ze mi IDE nadrbe tie cervene vykricniky, ako si tu niekto robil srandu, je dost pomoc.  Aspon si viem povedat "UPS", toto som nemal robit, alebo skontrolovat miesta vyskytu vykricnikov a zistit, ci ide o lahko fixnutelnu blbost, alebo sa na zmenu radsej vyserem, je napomocne. Prechadzat miesta, kde mi kompilator zarve chybu vo vim, to si radsej ukusnem ruku a zbabelo s placom a pokakany uteciem do lesov, aby som olizoval koru zo stromov. Alebo debugovat vo vim unit test, ktory mi zarve, aaah ....

Vim si v průběhu času vytuní každý podle svých potřeb a konfiguraci si přenese mezi všemi používanými instancemi.

K čemu jsou dobré ty červené vykřičníky v IDE? Vim mi je nedělá a nedělá je ani IDE, které otevře soubor po editaci ve Vimu. Po kompilaci skočí Vim na místo, kde byla hlášena chyba. V čem je problém?

V tomto, co ste napisali, je to strasne neprakticke.

[balki]

To, ze IDE ludom pri programovani pomaha, v tom nevidim problem. Pri programovani sa pouzivaju rozne barlicky, IDE, ake je neinvazivne (Tj nenadrbe svoje custom hacky do kodu), tam nevidim problem.

Vidím problém v tom že IDE lidem při programování pomáhá vytvářet junkcode, ve kterém nepomůže najít jiné chyby, než syntaktické.

Junkcode sa da robit aj vo vim. Staci programovat copypasta stylom, ktory je oblubeny najma v pythone a javascripte, ako ukazali prieskumy na githube.

[Kit]

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

Měnit názvy veřejných metod, které se už používají, není refaktoring, ale zvrhlost.

Ak sa zle volaju, nevidim v tom problem.

Nerozumím tomu "zle volaju". Jak ji mohou špatně volat, když ji volají dle definovaného rozhraní?

Když v IDE změním název veřejné metody v nějaké třídě, v kterých projektech se mi změní i její volání?

[Kit]

Po kompilaci skočí Vim na místo, kde byla hlášena chyba. V čem je problém?

V tomto, co ste napisali, je to strasne neprakticke.

V čem je to nepraktické? Kam má skočit?

[balki]

Po kompilaci skočí Vim na místo, kde byla hlášena chyba. V čem je problém?

V tomto, co ste napisali, je to strasne neprakticke.

V čem je to nepraktické? Kam má skočit?

Tvarite sa, ako by ste nepouzivali nikdy GUI. Skakanie na chyby pri kompilacii, je drevene. Povedzme, ze si chcem pozriet par vyskytov, potom to po castiach pofixovat a pozriet, co mi to urobi v testoch. Zdebugovat testy. Nieco vratit naspat, lebo usudim, ze cast zmeny bola kravina a treba to spravit inak. Co vam poviem, uzasny svet grafickeho pouzivatelskeho rozhrania.  Fixovat vo vim skakanim po suboroch, to by sa radsej na zmenu vysral, len lepil dalsi kod a modlil sa, ze som prilepil spravne. (Robim si zadek, som ateista, nemodlim sa.)

[balki]

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

Měnit názvy veřejných metod, které se už používají, není refaktoring, ale zvrhlost.

Ak sa zle volaju, nevidim v tom problem.

Nerozumím tomu "zle volaju". Jak ji mohou špatně volat, když ji volají dle definovaného rozhraní?

Když v IDE změním název veřejné metody v nějaké třídě, v kterých projektech se mi změní i její volání?

Mají špatný název,  pane.  Přomintě, že mi nerozumíte.