Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Bystroushaak

Stran: 1 ... 3 4 [5] 6 7 ... 13
61
Studium a uplatnění / Re:Jaký programovací jazyk zvolit?
« kdy: 27. 07. 2016, 14:30:56 »
Bystroushaak: hezká pohádka, ale takhle získávání zakázek nefunguje.
1. Většina firemních zákazníků dá přednost známé firmě s referencemi a se zázením před freelancerem nebo jednočlenným s.r.o.
2. Na ten příklad snad jde použít existující ERP systém nebo systém pro samostatné skladové hospodářství. Existuje to i jako freeware.

*se podívá na účet a na šanon s nápisem zakázky*

Dík. Jsem rád, že mi řekneš jak co funguje, asi ty prachy dojdu vrátit, nebo co. To co jsem popsal nejsou nějaké teoretické zážitky a spekulace o tom jak to funguje, je to část toho, co jsem řešil a dostal jako nabídky minulý rok.

Je mi fakt úplně jedno, čemu dá přednost většina lidí a jaký existuje software. Zajímá mě, co chce a zaplatí zákazník. Reálně mě prostě lidi s tímhle oslovují každou chvíli a zakázek podobného stylu je strašně moc, i když úplně vynechávám weby.

Firmy s referencemi se pohybují v úplně jiných částkách a jakýkoliv custom software od nich je buď totální krám (zajavená uzavřená nekonfigurovatelná příšernost, na kterou uživatelé nadávají a můžou tak leda zapomenout, že k tomu dostanou zdrojáky*), nebo stojí šesticiferné částky.

*což kupodivu po tom co se spálili docela dost lidí chce, protože pak mají možnost dalšího vývoje, místo aby jim firma za dva roky řekla, že smolíček, verze už se nevede, ale za dalších 3 miliony vám uděláme novou.

62
Studium a uplatnění / Re:Jaký programovací jazyk zvolit?
« kdy: 27. 07. 2016, 13:20:48 »
Ach jo. Ale co už, čekám, než zabere kofein a mám pauzu na oběd, tak teda;

Nauč se Python.

Proč?

Jednak je to fajn jazyk a prostředí. Dělám v něm a dělal jsem i v javě a dalších, takže to vím.

Co je ale podstatnější, tak ho většina VŠ na rozdíl od Javy, C# a dalších neučí a trh je masivně hladový. Nebudeš muset bojovat s celou generací právě vyšlých studentů.

Momentálně dělám jednoho ze tří programátorů ve firmě a snažíme se nabrat další, takže jsem docela často u rozhodovacího procesu a u pohovorů. V minulé práci jsem měl taky několikrát tuhle příležitost, takže trochu vím, o čem to je.

Programování není jen o jazyku. To je naprostý základ, stejně jako psaní knih není jen o češtině. Tak jako se autor knih musí naučit vyprávět příběh, vytvářet zápletky a předkládat před čtenáře děj, tak se musíš naučit složitost algoritmů, členění programu do strukturovaných kusů (jeden by nevěřil, kolik se nám hlásí lidí, co dají jako ukázku  jednu nablitou 500 řádkovou funkci), standardní knihovnu, hledání a používání knihoven ostatních lidí. Základy linuxu, instalaci závislostí z package managerů a vytváření ucelených kusů kódu (=třeba vlastní balíčky).

Další důležité věci, které naprostá většina vysokoškoláků nedává je psaní dokumentace (myšleno docstringů tříd/metod/funkcí), práce s gitem (víc než jen "tohle je první commit") a unittesting. Přitom to jsou tři reálné věci, které v libovolné práci budou dělat od rána do večera. Je to pro ně to samé, co pila a malá sekerka pro dřevorubce - sice to není hlavní pracovní nástroj (=jazyk), ale používá se to každou chvíli.

Další věc, kterou vysokoškoláci naprosto postrádají, i když by jim to měla vysoká škola dodat, je rozhled. Prostě nemají vůbec tušení kde jsou, co je jejich kontext, jak má vypadat jejich práce, co jsou „sousední“ technologie a jak zapadají do světa, co generuje zisk a tak podobně. Málokdo z nich umí anglicky na přijatelné úrovni.

Citace
Dokázal by mi s tím někdo pomoct?

Pomáhat ti nikdo s ničím nebude, protože reálně nikoho nezajímáš. Zvykej si.

Všechno co budeš potřebovat se musíš naučit sám. Stejně tak každá práce, kterou kdy budeš dělat bude tak z 50% o tom co znáš a ten zbytek se musíš naučit během chvíle dynamicky, jinak jsi k ničemu a tohle není obor, který bys měl dělat.

Nauč se anglicky, sleduj programátorské komunity, ale ne jen pasivně, taky se zapoj. /r/programming je dobrý výchozí bod. Čti všechno co tam vyjde (hodí se RSS čtečka), orientuj se v tom, zjišťuj si co co znamená a jak to zapadá do kontextu s ostatním.

Pokud chceš úplně nejužitečnější radu: dělej vlastní projekty. Prvních 50-100 tisíc řádků, které napíšeš budou sračka. S tím se prostě nedá vůbec nic dělat, kromě toho se vypsat. Když vidím vlastní zdrojáky třeba jen tři/čtyři roky zpět, tak mám pocit, že bych se nafackoval a to programuju už 10 let.

Na začátku zapomeň na nějakou monetizaci. Prostě si piš vlastní projekty, dělej věci, které ti přijdou zajímavé a jsou pro tebe výzva. Vyzkoušej si programování grafických aplikací, práci s internetem, parsování HTML/XML, IRC bota, email klienta a tak. Naimplementuj si pár RFC, abys věděl jaký to je pocit. Zapoj se do nějakého existujícího opensource projektu a udělej tam třeba 100-200 commitů.

Neexistuje žádná zkratka. Kdokoliv, kdo ti bude tvrdit opak je lhář a chce tě jen zmanipulovat, aby sis koupil nějakou jeho knížku, nebo kurz, nebo nějakou takovou debilovinu.



Některé z těch vlastních projektů zahoď, ale ty povedenější dej na github. Dotáhni komentáře, dokumentaci, balíček, unittesty, vlastní styl, „python way“ dělání věcí.

Vlastní portfolio na githubu je strašně moc důležité. U nás ve firmě, kdo nemá něco na githubu, ten ani nemá šanci dostat se k pohovoru.

Reálná zkušenost z života: Poslední 4 práce mi získal github.

Slyšel jsi o takových těch pracovních pohovorech, kde po tobě chtějí fizzbuzz, dávají ti dělat projekty, psát algoritmy a tak? Kde se tě ptají na kraviny, jako jaká je tvoje oblíbená barva a jak by ses charakterizoval v pěti slovech? Situace, kde tě schválně na pohovoru stresují, aby viděli, jak si poradíš s řešením úlohy?

Nic z tohohle se tě netýká, když máš github plný projektů a pár tisíc commitů v commit logu.

Přijdeš jako Paša, chvíli se bavíš s budoucími kolegy o nějakém svém projektu, proč jsi udělal tohle, jaký používáš styl, proč používáš napoleon doc misto numpy stylu, a pytest místo unittest knihovny přímo v pythonu. Zcela přátelsky si pokecáte o různých dalších projektech, o NoSQL databázi, co jsi použil minule, o výhodách a nevýhodách bottle.py web frameworku, tvém oblíbeném ORM a co se zrovna učíš za toy jazyk (smalltalk, lisp, erlang, haskell a tak).

Pak si domluvíte nástupní plat a kdy chceš nastoupit a to je všechno. Možná se ještě z pohovoru i něco nového a zajímavého dozvíš, protože se to přesune z pozice „jsem zkoušen“ do pozice „s budoucími kolegy řeším mé projekty a novinky, abych ukázal rozhled“.

To si necucám z prstu, jsou to reálné zkušenosti a přesně takhle to probíhalo.

Citace
Pracuje někdo na zakázky? Jak to probíhá?

Během minulého roku jsem dělal několik zakázek. Funguje to tak, že někde začneš pracovat a děláš programátora třeba rok / dva, než se to naučíš. Jakmile se roznese, že jsi co k čemu, tak tě lidi začnou oslovovat se svými problémy. Celé to funguje naprosto sociálně a neformálně, takže se vyplatí nebýt autistou a mít i nějaké známé.

Příklad: Jdeš na oběd se sestrou a ta vezme i kamarádku. Kamarádky rodina má malou vinárnu a když se zmíníš, že jsi programátor, tak si vzpomene, že by potřebovali software na evidenci vína. Něco, co když půjde babka do sklepa a vezme tři láhve, tak aby si na tabletu odškrtla ty tři lahve tak, aby se je potom nesnažil otec prodat, tzn musí to mít i webové rozhraní. Rozpočet sto tisíc.

Příklad: Přijde kolega z jiného oddělení a v rámci socializace jdete na jídlo. V průběhu se jen tak zmíní, že mají pracovníky, kteří dělají některé poměrně složité věci a analýzy manuálně a jak je život nahovno, protože to nestíhají a potřebovali by nabrat tak 20 dalších lidí. Ty řekneš, že to je přesně práce programátora, tyhle věci jim usnadňovat a zefektivňovat a že by si měli někoho najmout, kdo by jim udělal custom software, který tu práce zautomatizuje. Za měsíc se ti ozve, že to prohnal přes vedení a že pro tebe má zakázku, rozpočet je 90 tísíc.

Příklad: Jdeš s bráchou do cider baru a chlastáte do noci, než se to rozhodnete zabalit. Cestou na bus narazíte na mix kavárny a hospody, před kterým stojí nějaký váš známý, který trvá na tom, aby jste zachlastali spolu. U stolu jsi v rychlosti představený asi 7 náhodným lidem, z nihž jeden dělá tatéra, další navrhuje mrazáky a další pracuje někde v helpdesku. Když řekneš že jsi programátor, jeden z nich se hned začne zmiňovat o nějaké zakázce na psaní webu.

Příklad: Tvůj kolega z jiného oddělené byl spokojený s odvedenou prací, takže tě pochválí u dalších kolegů. Jeden z nich je šéf oddělění, kterého už nebaví si objednávat validátory dat u externích firem, kde každý balíček stojí dva miliony, nemají k tomu zdrojové kódy a firma se chová jak zadek. Takže se ti ozve, že by pro tebe měl zakázku za 350 tisíc, tady jsou specifikace, věděl bys jak na to? Časový rozpočet tři měsíce.

Tohle jsou zcela reálné zážitky. Něco z toho jsem přijal, jiné věci jsem odmítl, většinou čistě z důvodu, že jsem něměl čas, protože už jsem dělal o víkendech a po včerech něco jiného.

Pokud chceš dělat tenhle druh práce, mám k tomu několik poznámek:

1. Je to psychicky náročné. Počítej s tím, že ti to žere čas, pokud to neděláš na fulltime, ale taky musíš sám sebe donutit pokračovat. Když narazíš na problém, tak ho musíš překonat. A pak znova a znova a do toho plnit deadline a psát dokumentaci a unittesty a starat se o nasazení a dvacet dalších věcí. Někdy máš zásek třeba týden / dva a strašně moc se ti do toho nechce, ale musíš, nebo udeří smluvní pokuty.

2. Pokud děláš na IČO, stát tě obere na daních docela hodně. Kdybys vzal třeba tu zakázku za 350 tisíc, tak bys z toho reálně měl něco pod 270 (daně, sociální, zdravotní a další sračky). To zní pořád super, ale jak dlouho to budeš dělat? Kolik u toho budeš mít stresu? Fakt zvládneš všechno, nebo si na něco budeš muset najmout dalšího člověka? Co když to projedeš časově? Chce se ti platit 2 tisíce pokuty za každý den zpoždění? Jsi připravený řešit reklamace?

3. Chce to vizitku, kterou dáváš lidem, kteří projeví náznaky zájmu. Sice se to může zdát v dnešní době facebooků a mobilů docela k ničemu, ale vizitka cestuje světem sama o sobě, je předávána z člověka na člověka a často se dostane někam, kde bys to vůbec nečekal.

4. Potřebuješ ukázky práce, kterou jsi udělal.

5. Občas se stane, že lidi nezaplatí. Zatím jsem měl štěstí, ale brácha už se soudil. Najednou musíš řešit právníky, vyhrožovat si a tak a je to rychle ošklivé.

---

No nic, domluvil jsem. Chtěl jsi informace, tak jsi je dostal. Jak si je přebereš je jen na tobě.

63
Odkladiště / Re:Zastoupení Apple mezi uživateli
« kdy: 26. 07. 2016, 10:48:27 »
Linux zrovna v pohodě na macu neběží, pokud tedy nemluvíš o virtualizaci. Možná na novějších modelech, ale co jsem to zkoušel já, tak docela tragédie.

64
Odkladiště / Re:Zastoupení Apple mezi uživateli
« kdy: 25. 07. 2016, 15:50:11 »
Zartujes?

sudo easy_install pip

Potrebujes na vyvoj v Pythone nieco viac?

To bych teda kurva řekl. Ve chvíli kdy má něco dependencies na Cčkový projekty, tak je to občas porod nainstalovat i na linuxu, na tož pak na macu, kde tě polovina dependencies odkáže tak leda na ty issues v githubu, kde někdo dva roky úpěnlivě prosí, aby to tam přidali.

65
Odkladiště / Re:Zastoupení Apple mezi uživateli
« kdy: 25. 07. 2016, 14:43:57 »
Co já vidím, tak Apple je docela hodně rozšířený mezi frontend developery a webaři. Pak grafici, management a tak, ale to už mě moc nezajímá.

Osobně jsem si taky pořídil starší macbook a dal tomu měsíc, abych si otestoval jak se v tom dělá. Zjistil jsem, že mě to extenzivně opruzuje na mnoha různých úrovních. Jmenovitě klávesnice - na klasickou českou prostě zapomeňte a speciální znaky tak jak se píšou třeba ve windows a linuxu (pravý alt+něco) prostě nebudou. Další věc je, že ačkoliv mac nabízí package managery (tím nemyslím oficální od apple, ale brew), tak více/méně zejí prázdnotou a třeba pro vývoj v pythonu se to naprosto nehodí a je docela opruz tam natahat všechny závislosti a tak. Kdykoliv kdy jsem chtěl něco „navíc“, tak prostě hodiny googlení, stahování jakýchsi špinavých poflusaných binárek z plesnivých částí internetu, jak někde na windows a neustálé narážení na uzavřenost a omezenost systému (jen třeba donutit to, aby to vypisovalo ve finderu složky před soubory je docela porod).

Pak jsem tam po měsíci nacpal linux, ale podpora je bídná, vypadával zvuk, pak zas klávesnice opruzovala a tak, takže jsem ho prodal. Po téhle zkušenosti, když mi teď v práci nabídli, jestli nechci macbook pro, tak jsem odmítl a radši mám nějakého della, i když ten má taky své problémy.

Na druhou stranu chápu lidi, proč to používají. Pokud někdo nemá moc velké nároky, nebo na macu začíná, tak je to perfektně odladěný systém. Jakmile od něj ale chcete něco víc, tak je to uzavřené peklo, kde prostě ani nic nevygooglíte, protože to prostě apple zakázal a basta.

66
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 06. 06. 2016, 07:35:00 »
Čistě moje subjektivní zkušenost:

Nemám nic proti systemd jako initu. Je mi docela ukradené, jestli se píše script, nebo nějaký konfigurák. Zrychlení bootování? Fajn.

Problém je, že systemd není jen init. Ta sračka snědla půlku linuxu a pořád se rozpíná dál. Myslel jsem, že se asi poseru, když jsem před půl rokem dostal v práci pár serverů ať na nich něco udělám a nebyl jsem schopný ani spustit síť, protože půl linuxu bylo nahrazeno systemd blbostma a já se můžu po 10 letech spokojeného adminování v malém všechno přeučit.

Někdo to dobře vyjádřil tímhle gifem:



Poslední kapka pro mě byly ty jejich plány na nahrazení cronu a teď jak si vymysleli, že budou killovat běžící procesy po odhlášení uživatele, takže tmux, screen a byobu musí dělat úpravy. To ani nepočítám notoricky špatnou podporu a neochotu opravovat bugy celé roky. Celý ten jejich přístup je jedna gigantická arogance ke zbytku komunity.

Myslím, že to je ten důvod, proč jsou „všichni“ proti systemd.

67
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 19:53:48 »
Já jen - všímáte si, že diskuze jde přesně tím směrem, co jsem popsal? Dokonce už je tu i javaman, který nám udělal kázání o lopatách co pracují za polovinu.

Už si skoro říkám, jestli by to nestálo za napsání článku, který by se pak vždycky jen odkazoval, protože teď se to bude vše znova opakovat. Pokolikáté už za poslední půlrok? Potřetí?

http://forum.root.cz/index.php?topic=12988.0

Jsem vychazel z wiki:
Citace
Metaobjects are examples of the computer science concept of reflection, where a system has access (usually at run time) to its internal structure.
...
A metaobject protocol (MOP) provides the vocabulary to access and manipulate the structure and behavior of objects.

To tedy dost pusobi jako reflexe ci prace s bytekodem, pokud to mam vztahnout k Java svetu. Ale je to asi jedno, me neslo o ty metaobjekty ani metaobjektovy protokol, ale o to inovativni jmeno: __*__, ktere bych nikdy neoznacil za hezke - coz uznavam je asi subjektivni a pravdepodobne o zvyku.

Reflexe nepracuje s bytekódem, ale přímo s objekty, které můžou zkoumat svojí vlastní strukturu, třídy, chain dědičnosti a různě jí upravovat. Někdy to může ušetřit kód pomocí pokročilé magie, jindy tě to může střelit do nohy.

Sice jsem odkazoval jen slovo „metaobjektového“ (protože to spousta lidí nezná), ale důležitý je celý zbytek té věty, hlavně to „protokolu“. V pythonu magické metody vytvářejí standardizovaný protokol pro komunikaci s objekty definující často používané akce. Dalo by se říct, že je to takové rozhraní pro standardní funkcionalitu, které podporuje sám jazyk. Třeba __str__() se zavolá při konverzi na string a __repr__() při „zobrazení“ objektu v konzoli atd..

Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?

Proč vůbec diskutuješ o věcech, kterým od pohledu nechápeš?

V Javě ani Pythonu by se k atributům objektu z vnějšku přistupovat nemělo. A to ani prostřednictvím getterů/setterů. Mělo by se pracovat přímo s objektem, tedy volat jeho metody, které data uvnitř objektu zpracovávají jak pro vstup, tak i pro výstup.

V pythonu je to imho jedno, protože podporuje properties. Ve chvíli, kdy potřebuješ přístup omezit či nějak transformovat, můžeš tak učinit přes property, či přes deskriptory.

Osobně mi snaha omezovat přístup a myslet si, že tím zlepšuji bezpečnost (nebo co vlastně?) jako nesmysl. Je stejně absurdní, jako snaha některých výrobců omezovat co můžu dělat s mobilem který si koupím a co už ne. Když prostě budu chtít znásilnit nějaký objekt a vlézt si do něj, tak to udělám ať už v javě, nebo kdekoliv jinde, i kdybych to měl dělat scannováním a živou úpravou /dev/mem.

V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?

To proto, že java nemá žádnou vnitřní logiku, ani krásu. Celé to tak je, prostě proto že to tak někdo chtěl (navíc někde v C++, nebo ještě hlouběji v historii), nikoliv proto, že by to dávalo vnitřní smysl. Neroste to z žádného silnějšího vnitřního konceptu, jako některé jiné jazyky (smalltalk, lisp, do jisté míry i python, který vše staví na dictech).

68
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 17:55:12 »
V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.

Tak to je samozřejmě pravda. S velkým důrazem na ty „základní věci“, které jsou většinou méně výraznou součástí informace, kterou od dokumentace chci. Primárně vědět „co to dělá a proč“, než „nad čím a co z toho leze“.

Python i Haskell má stejný problém. Nepíše se dokumentace.

Citation needed.

Jen pro pořádek, zrovna o dokumentaci v pythonu mám rozepsaný článek*, který shrnuje mé zkušenosti z používání mnoha desítek opensource knihoven a dokumentace se píše. Dokonce celý populární ReadTheDocs, který je dneska používaný pro velkou část všemožného OSS vznikl z pythonního dokumentačního systému Sphinx.

Rád bych tedy věděl, z čeho usuzuješ, že je to podstatný problém, protože si opravdu nejsem vědom toho, že by se nepsala dokumentace. Spíš bych řekl, že naopak - pokud někdo nepíše dokumentaci, tak nemá vůbec šanci uspět se svojí knihovnou. Uznávám, že nevím, jak je na tom haskell. Různé jazyky jsou různé, ale nepouštěl bych tvrzení o pythonu jen na základě zkušenosti s haskellem.

*součást většího seriálu o pythonu v praxi, datum vydání nejdřív za pár měsíců.

69
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 16:29:30 »
A nechtěl by sis přečíst celý můj příspěvek? Tak hrozný romány to zase nejsou...

Četl jsem*, argument je stále stejný. Tohle je problém který vůbec nesouvisí s pythonem, protože je stejný všude. Špatně udělanou dokumentaci prostě typový systém nijak nespasí. Nehledě na to, že když je takhle prasácky udělaná dokumentace, tak nemám žádný důvod předpokládat, že typové anotace budou dobře.

*pokud se v tom teda neztrácím.

70
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 16:19:54 »
Když mám mám v Pythonu funkci:

def format(a):
   """Formátuje argument a"""
...

tak mám dělat jako co prosím?

Aha, protože tohle je fakt problém pythonu a vůbec ne demence vývojáře, která se nedá napsat v libovolném jazyce. Fakt by mě zajímalo, co se tím přesně snažíš dokázat, protože to samé můžu napsat v libovolném jazyce, třeba v Javě:

Kód: (java) [Vybrat]
// Formátuje a.
public static string format(Object a){
    ...
}

To ti ty typové anotoce fakt pomůžou, že?

71
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 16:14:19 »
Rozhodne neobhajujte neco, jen proto ze v tom delate. Mam podezreni, ze to je duvod, proc tu to PHP jeste porad strasi. Vyvijim v JavaScriptu a rozhodne nemam potrebu ho do nebe vychvalovat. Mam na neho spise neutralni nazor, rozhodne by me nenapadlo vsem cpat NodeJS na server, kdyz si myslim, ze se to hodi jen na mikro weby (v podstate nastejno jak ten Python nebo Ruby).

To rozhodně nemám v plánu.

Jinak dělám v py nikoliv proto, že bych musel, nebo protože by mi to bylo vnuceno někde na škole. V roce 2007 jsem zkoumal co dál, tak jsem sepsal 2 stránky pro a proti všemožných jazyků, všechny je prozkoumal, pročetl wikipedii, homepage, zkusil si je nainstalovat a napsat v nich něco triviálního, ohodnotil je subjektivními body a pak si z nich vybral python. A od té doby v něm dělám a posledních několik let mě za to i lidi platí.

Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).

Zrovna tohle je typický argument. O pythonu už jsem tu vedl několik diskuzí, které vždycky skončí stejně: já ukážu na nějaký projekt, dodám zkušenost s práce na větším systému (desítky tisíc řádků podle cloc bez komentářů, prázdných řádků a tak) a ostatní se hádají, že to prostě nemůže fungovat, i když to funguje.

Pak se to zvrhne na hádku o typových systémech, kde javisti dokazují, že když to nefunguje jako v javě, tak to nemůže být použitelné pro cokoliv kromě trivialit, pythonisti se frustrovaně snaží vysvětlit, že to fakt funguje, což je prostě pozorování, ne teorie, pak přijde někdo s tím, že ducktyping je bullshit a že mu nerozumí, haskellisti, ocamlisti a další typoví guru se smějí na pozadí. Do toho přijdou lopaťáci, kteří začnou vykřikovat cosi o lopatách, trolové, kteří prostě jen krmí některý z táborů čímkoliv, na co budou reagovat a drama je na světě.

Ono vůbec, u pythonu narážím na to, že spousta lidí vůbec nechápe, že má svojí vlastní filosofii a nejde jen tak přijít z javy, naučit se základy syntaxe a začít v něm javit, protože pak z toho lezou výblitky, které je horor udržovat a tohle pak javisti berou jako důkaz, že python nestojí za nic.

Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).

Skvělá šikmá plocha. Protože lopatička není koloběžka, tak ani v javě se nedá psát komplexní projekt.

Že to nedává smysl? No, to tyhle jazykové analogie fakt nedávají, což ale nikomu nebrání je používat, že. Tady se třeba cosi snažíš dokázat na TeXu, který má s pythonem společného co? Nic.

Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.

Já mám zas pocit, že nemáš tušení co je to OOP, ani FP. Modifikátory přístupu například vůbec v původním OOP (smalltalk, self) nebyly a ani být nemusí. To je jen demence, když to pak roubovali na pokroucený zprasený systém C++ a Javy (Oaku, heh).

Python podporuje „privátní“ atributy pomocí __, kde ti interpreter vyhodí chybu, když k tomu zkusíš přistoupit.

Kód: [Vybrat]
>>> class Xe(object):
...  def __private(self):
...   return 1
...
>>> x = Xe()
>>> x.__private()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Xe' object has no attribute '__private'

Na druhou stranu ti v tom fakt nebude bránit, pokud víš co děláš:

Kód: [Vybrat]
>>> x._Xe__private()
1

Což je podle mě v pořádku. Když programátor fakt ví co chce, tak si může dělat co chceš a ty jako programátor knihovny mu v tom nezabráníš, i kdyby ses posral a nadefinoval si private úplně všechno. To jen lidi co přichází z Javy / C# mají urputný pocit, že když to neudělají, tak dojde ke konci světa. Nedojde. Prostě to spadne někomu, kdo dělá věci co by neměl, což není můj problém. Naopak progrmátorům, kteří ví co dělají a třeba chtějí jen mocknout nějakou hodnotu pro účely testování to může ušetřit shitload práce.

Jinak kdysi jsem na tom byl stejně, takže chápu, kde se tahle mentalita bere, můžu tě ale ujistit, že je to falešný pocit nutnosti něčeho, co fakt nutné není.

__háky__

Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.

Hahah. Tohle mě pobavilo, hlavně proto, že pamatuju ještě ty časy, kdy tomu tak nebylo a lidi argumentovali proti pythonu tím, že je nepopulární a v čechách v něm moc lidí nedělá. Teď je populární a lidi argumentují zase opakem :D

72
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 14:22:07 »
Mám dílema:

Obhajovat Python, protože v něm konec konců dělám, je to relativně dobrý jazyk a je pro mě dobré, když v něm bude dělat víc lidí, kteří vytvoří víc knihoven, a vůbec udělá víc příležitostí pro mě.

nebo

Nechat místní trolly a omezené javisty na python plivat, což třeba odradí některé nováčky, ze kterých by v budoucnosti mohla být konkurence. Nestojí to žádnou práci a konec konců mi může být v zadeki, co kde kdo vykládá.

Co byste vybrali vy?

73
Vývoj / Re:Má Python budoucnost?
« kdy: 12. 05. 2016, 13:48:44 »
... zatímco my mluvíme o přímém přiřazení a.temperature = 123.
Viz několik příspěvků zpět. Přetížení přiřazení.
V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.

Tohle se běžně neřeší přes __setattr__, ale setter dekorátor.

http://stackoverflow.com/questions/6618002/python-property-versus-getters-and-setters

74
Odkladiště / Re:Jaké IT weby sledujete?
« kdy: 10. 05. 2016, 16:00:58 »
Bystroushaak, Eda Beda: Stíháte při tom provozu taky něco dělat?

Většinou to nečtu každý den, nechávám si na to den / dva v měsíci, kdy to profiltruju a do instapaperu si z toho naházím zajímavé články, ze kterých většinu přečtu ještě ten den a zbytek různě když mám chuť.

75
Vývoj / Re:Nakažení GPL licencí v Pythonu
« kdy: 14. 04. 2016, 21:37:52 »
Linux (jádro) je licencován pod GPL 2 ale málo známý(nebo snad často zamlčovaný :) ) fakt je že  je tam cosi jako vyjímka pro uživatelské aplikace používající normální systémová volání. https://www.kernel.org/pub/linux/kernel/COPYING hned první část úplně nahoře.

Také  základní systémová knihovna která je potřeba ke kompilaci téměř čehokoliv, glibc, obsahuje vyjímku, která omezuje dosah licence pouze na knihovnu. Takže ji můžete použít v jakkoliv licencovaném programu aniž by jej to jakokoliv licečně ovlivnilo.

Díky za info, tím se to asi vysvětluje.

Pokud je to čistá GPL a nevyhovuje vám, doporučuju se jí vyhnout a pokusit se najít nějakou jinou knihovnu s vhodnější licencí.

Já teď jedu čistě MIT a GPL se radši vyhýbám. Z mého uhlu pohledu jsou s ní jen problémy.

Stran: 1 ... 3 4 [5] 6 7 ... 13