Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: petrrjan 27. 07. 2016, 11:36:48
-
Zdravím, chtěl bych se zeptat, jelikož přemýšlím, že bych se začal věnovat programování naplno, jaký jazyk si zvolit? Byla mi doporučená Java, ale přemýšlím také o C. Co lze těmito jazyky konkrétně naprogramovat a co již v dnešní době naprogramováno je, abych měl představu, co by pro mě do budoucna bylo větším přínosem. Rád bych během studia získával zakázky a pracoval z domova jako přivýdělek, ale nemám představu, který jazyk je v dnešní době perspektivnější a žádanější. Freelancer... Rok jsem měl na škole základy C v DOSu. Jaký software zvolit? Jak začít, jak jste začínali vy? Dokázal by mi s tím někdo pomoct? Pracuje někdo na zakázky? Jak to probíhá? Dnes je tolik jazyků, vůbec se v tom nevyznám. Díky za každou radu ;).
-
DOS ? :o Kdy to bylo ? Víc jak deset let zpět ? Co jsi dělal doteď, úplně jiný obor ?
-
Cobol jednozačne v dnešnej dobe je to nutnosť.
-
Ja bych doporucil Fortran, neni v tom prilis velka konkurence...
-
Nic proti, ale prijde mi, ze jsi chodil do skoly nekde v rovnikove Africe, rok tam sel el. proud a pak uz ne, je to tak? Doporucuju zvolit nejake jine remeslo, ktere je Tvemu srdci blizsi.
-
To fakt nedává valný smysl.
Ve škole jsi mě rok základy C v DOSu? A v jakém roce to bylo? Byla to základní škola, nebo střední?
A teď jsi na jiné škole a chceš si přitom přivydělávat vývojem? Na jaké škole jsi v jakém ročníku?
Jestli se chceš naučit programovat (a nejsi na škole, kde se to učí/bude učit), tak fajn - jazyků je hodně. Pro začátečníka je vhodný třeba python, nebo java. Můžeš zkusit začít programovat web v nějakém PHP, to bych teď nechal jako vedlejší.
Zaměřil bych se na to, že se chceš naučit programovat, aby sis při studiu vydělával programováním. Takže na to rovnou zapomeň. Peníze za programování dostane někdo, kdo už toho sám HODNĚ umí. Kdo nějaký komerčně požadovaný jazyk ovládá a doloží v něm alespoň pár semestrálek, nebo nějaké malé vlastní projekty. A to se bavím o situaci, že bys někam docházel a seděl vedle někoho a pracoval na konkrétních malých úkolech podle jasného zadání.
Že bys bys schopen pracovat samostatně jako freelancer, tedy dokázat zanalyzovat problém, jestli bys ho uměl řešit a jak bys ho řešil a případně dokázal říct kdy a za kolik ho vyřešíš - na to zapomeň úplně. Pokud bys uměl velmi dobře programovat, tak freelancera bych ti nedoporučil než po aspoň 3 letech práce na plný úvazek v nějakém programátorském týmu.
Jak začínala většina lidí?
Většina lidí začínala tak, že je k tomu buď někdo přivedl a začínali s tím jako s kroužkem, nebo koníčkem na základní nebo střední. Nebo to měli jako předmět na odborné střední škole.
Tak se většina naučila tak nějak základy a menšina to už na střední (během několika let) zvládla tak, že mohli rovnou nastoupit do nějaké firmy na pozici "úplný blbec, nic neumí, ale možná z něj něco bude". V té firmě se pod vedením někoho během několika let takový člověk stal použitelným pro samostatnou práci.
Ten kdo nešel po střední hned do práce, tak většinou nastoupil na nějakou IT VŠ a tam do něj lili jak kvanta teorie, tak po něm chtěli programovat spoustu praktických a nepraktických věcí. V průběhu VŠ si prakticky všichni našli nějakou programovací brigádu - ale opět - chodili někam do firmy a první půlrok je nikdo nenechal na nic sáhnout samostatně.
V okamžiku dokončení VŠ měla většina lidí už jisté místo, kde už na půl úvazku pracovala a byla většinou samostatně použitelná.
Ale dělat freelancera by v tu chvíli IMHO většina pořád nezvládla.
-
Záleží na tom co chceš dělat. Lidem jako TVL a Inkvizitor se každopádně snaž vyhnout. Budou si na tebe vyskakovet jen proto, že mají víc let zkušeností i kdybys toho uměl víc než oni.
-
Záleží na tom co chceš dělat. Lidem jako TVL a Inkvizitor se každopádně snaž vyhnout. Budou si na tebe vyskakovet jen proto, že mají víc let zkušeností i kdybys toho uměl víc než oni.
Nestyď se a napiš, co má člověk s rokem školního programování C v DOSu dělat, aby dostával programovací zakázky, které by mohl dělat z domova.
-
Třeba tím "programovat pro DOS" myslel, že programovali konzolové aplikace. Dodnes má řada lidí zažito konzola==DOS.
Dokonce jsem jednou četl debatu nešťastníka co si koupil notebook s instalovaným Linuxem, nikoliv Windows a padlo tam vyjádření doslova "...Linux mi v DOSu píše, že...bla bla bla". On ten ten Linux snad ani neměl žádný WM. Nějakej Linpus či co to bylo, už nevim.
Jinak tyhle dotazy moc nechápu. Prostě si projdi pár jazyků a kterej se ti bude líbit, tak se jej nauč.
Nejlépe se jich nauč víc.
http://www.itnetwork.cz/jak-zacit-programovat-tvorit-aplikace-programy
-
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í (http://kitakitsune.org/raw/Programovaci_FAQ/) 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.
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 (http://reddit.com/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.
(http://kitakitsune.org/raw/Programovaci_FAQ/pictures/c431e537a606a4cf2e5000c899e61744.png)
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.
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ě.
-
Záleží na tom co chceš dělat. Lidem jako TVL a Inkvizitor se každopádně snaž vyhnout. Budou si na tebe vyskakovet jen proto, že mají víc let zkušeností i kdybys toho uměl víc než oni.
Inkvizitor hlavne absolvoval desitky pracovnich pohovoru a zazil uz docela dost kolegu a podrizenych na to, aby si udelal predstavu, co muze nabidnout clovek, ktery se rozhodne z nouze programovat, k dane praci nema vztah a mysli si, ze na nej vsichni cekaji s otevrenou naruci po par mesicich samostudia.
-
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ů.
Python je super, dokonce je to druhý nejlepší jazyk na světě (ten první ještě nebyl vynalezen) a máš pravdu v tom, že je po něm hlad.
Bohužel ale s těmi platy Python developerů to není zas taková sláva. Kdybych na jeden graf vynesl histogram platů developerů v Pythonu, C++, C#, Javě apod., tak Python bude ten nejvíc vlevo. Je to tím, že ten hlad je způsoben především z řad webařských firem, které prostě tolik neplatí.
-
Cobol jednozačne v dnešnej dobe je to nutnosť.
Ja bych doporucil Fortran, neni v tom prilis velka konkurence...
Toz, soufky si delat muzete, ale oba jazyky se pouzivaji. COBOL proto, ze na nem porad jeste bezi rada systemu, ktere jsou tak rozsahle, ze na ne radsi nikdo nesaha a jen je udrzuji, obcas podle potreby upravuji. Takze treba clovek, ktery ovlada COBOL a ma na nej nervy, muze mit hezky vedlejsak. Ale umet jenom COBOL asi moc perspektivni neni.
A Fortran se pouziva proto, ze snad zadny jiny jazyk nema takove kvantum odladenych knihoven snad uplne na vsechno. Takze fycikove a matematici kvuli vam nebudou prechazet na .NET, Javu nebo Python, aby "udrzeli prst na tepu modernich technologii".
-
...
To je úplná programátorská červená knihovna a s tím sháněním zakázek.
Problém je, že náš člověk nyní nic neumí. A než se dostane dál, tak tvoje moudra budou někde dávno zapadlá.
-
Cobol jednozačne v dnešnej dobe je to nutnosť.
Ja bych doporucil Fortran, neni v tom prilis velka konkurence...
Toz, soufky si delat muzete, ale oba jazyky se pouzivaji. COBOL proto, ze na nem porad jeste bezi rada systemu, ktere jsou tak rozsahle, ze na ne radsi nikdo nesaha a jen je udrzuji, obcas podle potreby upravuji. Takze treba clovek, ktery ovlada COBOL a ma na nej nervy, muze mit hezky vedlejsak. Ale umet jenom COBOL asi moc perspektivni neni.
A Fortran se pouziva proto, ze snad zadny jiny jazyk nema takove kvantum odladenych knihoven snad uplne na vsechno. Takze fycikove a matematici kvuli vam nebudou prechazet na .NET, Javu nebo Python, aby "udrzeli prst na tepu modernich technologii".
COBOL je jazyk systémů, které se v Česku vyskytovaly minimálně. V ČR je zanedbatelný počet otevřených COBOL pozic. Ale nejsme omezeni na ČR, takže vzhůru do západní Evropy, tam COBOL práce je.
Má to jeden drobný háček - člověk musí být HODNĚ zkušený programátor, aby zvládl udržovat nějaký starý kritický systém jedoucí v COBOLu. Pokud vím, tak ty pozice obsazují lidi, kteří COBOL dělali už kdysi - a tudíž ho perfektně ovládají. Doba, kdy budou firmy rádi za začátečníky v COBOLu možná přijde, ale zatím IMHO nenastala.
Fortran se v Česku dělal. Ale fakt nevím, kolik z těch věcí ve Fortranu zůstala a nepředělala se v posledních 20 letech do něčeho jiného. Buď C, nebo do nějakých specializovaných matematických balíků. Jak je na tom nabídka práce pro Fortranistu v ČR, to neposoudím.
-
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.
-
Nejlepší máš Javu, ale to jsem ti říkal. Je to nejlepší jazyk, který nemá konkurenci. Nějaký skriptovací Python může být fajn, pokud nemáš velké ambice. Ve svém věku bys je ale mít mohl. Je to rozdíl asi jako jezdit do práce na trakaři a nebo v Jaguáru. Obojí tě tam doveze, ale...
-
Nejlepší máš Javu, ale to jsem ti říkal. Je to nejlepší jazyk, který nemá konkurenci. Nějaký skriptovací Python může být fajn, pokud nemáš velké ambice. Ve svém věku bys je ale mít mohl. Je to rozdíl asi jako jezdit do práce na trakaři a nebo v Jaguáru. Obojí tě tam doveze, ale...
Nenech se javamanem odradit, ve skutecnosti java neni spatna volba. Nijak oslniva, ale spatna varianta to neni, jak z hlediska pouztelnosti a produktivity tak z hlediska uplatneni a penez.
-
Nenech si namluvit, že Java je průměrná volba. Java je špičková volba pro opravdové programátory. Skriptovací PHP/Python je spíše pro děti a začátečníky.
-
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.
-
Jsi na rootu plného pohádkářů, tak co čekat. Tady nikdo nic nezkusí, protože to přece nefunguje :D
-
Jinak já znám nefunkční krámy za desítky milionů, o ceně to není. Většina velkých firem produkuje předražené zmetky. Proto tu pořád bude trh pro menší a kvalitní zakázky.
-
COBOL je jazyk systémů, které se v Česku vyskytovaly minimálně. V ČR je zanedbatelný počet otevřených COBOL pozic. Ale nejsme omezeni na ČR, takže vzhůru do západní Evropy, tam COBOL práce je.
Tak COBOL bezel treba kdysi v Telecomu na nejake socialisticke hajtre s OS propasovanym na paskach ze zapadnich Nemec. Ale uz je urcite davno ve srotu a tym programatoru vystaven v muzeu informatiky.
Fortran se v Česku dělal. Ale fakt nevím, kolik z těch věcí ve Fortranu zůstala a nepředělala se v posledních 20 letech do něčeho jiného. Buď C, nebo do nějakých specializovaných matematických balíků. Jak je na tom nabídka práce pro Fortranistu v ČR, to neposoudím.
Rekl bych, ze se porad pouziva. Treba u strojaru, jako muj znamy, ktery vypocty delal zasadne ve Fortranu. Pochybuji, ze by se stari psi ucili nove kousky jen proto, ze nekdo predelal nejake knihovny do C. A otazka je, kolik jich predelal. Jestli se da rici, ze C ma dneska knihovny uplne na vsechno a ze jsou tak odladene a lety testovani ozkousene, ze je lze povazovat za totalne bombenfest.
V kazdem pripade, ani v COBOLu, ani ve Fortranu bych budoucnost nehledal. Ale take bych je nestavel na roven programovani batchu v DOSu, jak to tu nekteri vidi.
-
Nenech si namluvit, že Java je průměrná volba. Java je špičková volba pro opravdové programátory. Skriptovací PHP/Python je spíše pro děti a začátečníky.
Jenomze ony nejsou na svete jen tyhle tri jazyky a neni projekt jako projekt.
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Pokud jako "beznou praci" definujes jako neco, na co je nejlepsi Java.
-
Fortran se v Česku dělal. Ale fakt nevím, kolik z těch věcí ve Fortranu zůstala a nepředělala se v posledních 20 letech do něčeho jiného. Buď C, nebo do nějakých specializovaných matematických balíků. Jak je na tom nabídka práce pro Fortranistu v ČR, to neposoudím.
Rekl bych, ze se porad pouziva. Treba u strojaru, jako muj znamy, ktery vypocty delal zasadne ve Fortranu. Pochybuji, ze by se stari psi ucili nove kousky jen proto, ze nekdo predelal nejake knihovny do C. A otazka je, kolik jich predelal. Jestli se da rici, ze C ma dneska knihovny uplne na vsechno a ze jsou tak odladene a lety testovani ozkousene, ze je lze povazovat za totalne bombenfest.
Pro strojaře nevidím žádný důvod, proč by měl z Fortranu přecházet na pomalejší a komplikovanější C, které ani neumí pořádně pracovat s vícerozměrným polem či komplexními čísly. To už spíš na Matlab či free alternativu Octave.
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Co je to bezna prace? Zatim vse, co jsem v Jave videl, mi vyzralo CPU a RAM do mrte. Treba Jitsi se neda vubec pouzit, pokud nemas nadupanou masinu. Kdysi jsem zkousel ANts P2P a pak to zahodil, protoze bych tomu musel dedikovat PC. Podobnych veci v jinych jazycich spustim cele hafo a vsechny se mi do CPU i RAM vejdou najednou. Java je jiste vynikajici jazyk na monumentalni projekty srovnatelne s egytpskymi pyramidami nebo Stalinovym pomnikem na Letne, ale ne kazdy touzi stavet pomniky.
BTW, strasne rad bych videl treba plne nadupany web browser napsany v Jave. Joj, ten by byl rychly!
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Co všechno podle tebe ve vývoji softwaru spadá pod "běžnou práci"?
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
-
Co všechno podle tebe ve vývoji softwaru spadá pod "běžnou práci"?
Můžeš jí taky definovat jako duši sající nudu složenou z implementace UML definovaného architektem do doby, než vyhoříš a dojdeš se oběsit na lopatě.
Což je nejspíš to, co čeká na většinu studentů, kteří vyjdou s VŠ a jdou se ucházet o java job (bez toho věšení).
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Tak s tímto souhlasím, na PDE není nic lepšího. Snad jen jazyk, který pracuje s fortranskými knihovnami a poskytuje programátorovi nějaký lepší komfort. Java se v této oblasti moc nechytá.
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Co všechno podle tebe ve vývoji softwaru spadá pod "běžnou práci"?
40 až 100 HPP. Prostě obyč vývoj.
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Já se přiznám, že tomu kolem Fortranu nerozumím.
Tak třeba PDE:
Buď to potřebuji řešit na nějakém malém mikroprocesoru, nebo ARM, a bude to součást nějakého mobilního zařízení, nebo chytrého senzoru, nebo tak nějak. Pak je jasná volba C. Je rok 2016 a matematických knihoven v C je dost. Doba, kdy někdo používal mikroprocesor, co neměl kompilátor Céčka a lepil to v assembleru je snad za náma.
Na ARM a podobné stejně oficiální kompilátory fortranu neexistují a neoficiální bych se na důležité věci teda použít bál. A plnohodnotný procesor do nějakého malého senzoru stejně nedostanete (především cenově).
Nebo to potřebuji řešit v kanceláři na PCčku (nebo v laboratoři na nějakém výpočetním clusteru, to není podstatné). Pak existuje mnoho specializovaných (a luxusních) matematických balíků. Pravda, ne všechny cílí na špičkovou rychlost výpočtu, ale vždy tam bude zásadně vyšší rychlost vývoje.
Dobrá, pokud někdo počítá pořád totéž a má své fortranovské rutiny hotové, tak proč by je nepoužíval dál. Ale technika se vyvíjí, řekl bych, že většina výpočtářů potřebuje svoje modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové.
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Co všechno podle tebe ve vývoji softwaru spadá pod "běžnou práci"?
40 až 100 HPP. Prostě obyč vývoj.
Asi nejak starnu, ale zacinam mit problem rozeznavat troly od idiotu.
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Já se přiznám, že tomu kolem Fortranu nerozumím.
Tak třeba PDE:
Buď to potřebuji řešit na nějakém malém mikroprocesoru, nebo ARM, a bude to součást nějakého mobilního zařízení, nebo chytrého senzoru, nebo tak nějak. Pak je jasná volba C. Je rok 2016 a matematických knihoven v C je dost. Doba, kdy někdo používal mikroprocesor, co neměl kompilátor Céčka a lepil to v assembleru je snad za náma.
Na ARM a podobné stejně oficiální kompilátory fortranu neexistují a neoficiální bych se na důležité věci teda použít bál. A plnohodnotný procesor do nějakého malého senzoru stejně nedostanete (především cenově).
Nebo to potřebuji řešit v kanceláři na PCčku (nebo v laboratoři na nějakém výpočetním clusteru, to není podstatné). Pak existuje mnoho specializovaných (a luxusních) matematických balíků. Pravda, ne všechny cílí na špičkovou rychlost výpočtu, ale vždy tam bude zásadně vyšší rychlost vývoje.
Dobrá, pokud někdo počítá pořád totéž a má své fortranovské rutiny hotové, tak proč by je nepoužíval dál. Ale technika se vyvíjí, řekl bych, že většina výpočtářů potřebuje svoje modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové.
Nepoužívají ty vaše matematické balíky knihovny napsané ve fortranu?
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Já se přiznám, že tomu kolem Fortranu nerozumím.
Tak třeba PDE:
Buď to potřebuji řešit na nějakém malém mikroprocesoru, nebo ARM, a bude to součást nějakého mobilního zařízení, nebo chytrého senzoru, nebo tak nějak. Pak je jasná volba C. Je rok 2016 a matematických knihoven v C je dost. Doba, kdy někdo používal mikroprocesor, co neměl kompilátor Céčka a lepil to v assembleru je snad za náma.
Na ARM a podobné stejně oficiální kompilátory fortranu neexistují a neoficiální bych se na důležité věci teda použít bál. A plnohodnotný procesor do nějakého malého senzoru stejně nedostanete (především cenově).
Nebo to potřebuji řešit v kanceláři na PCčku (nebo v laboratoři na nějakém výpočetním clusteru, to není podstatné). Pak existuje mnoho specializovaných (a luxusních) matematických balíků. Pravda, ne všechny cílí na špičkovou rychlost výpočtu, ale vždy tam bude zásadně vyšší rychlost vývoje.
Dobrá, pokud někdo počítá pořád totéž a má své fortranovské rutiny hotové, tak proč by je nepoužíval dál. Ale technika se vyvíjí, řekl bych, že většina výpočtářů potřebuje svoje modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové.
Nepoužívají ty vaše matematické balíky knihovny napsané ve fortranu?
IMHO ne, jinak by nebyly o tolik pomalejší :-) Některé M balíky ale umí spouštět fortranovské zdrojáky. Počítám ale, že v tom bude komplilátor fortranu, co si sami napsali v C.
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Dobrá, pokud někdo počítá pořád totéž a má své fortranovské rutiny hotové, tak proč by je nepoužíval dál. Ale technika se vyvíjí, řekl bych, že většina výpočtářů potřebuje svoje modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové.
Pokud někdo potřebuje své modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové, proč by to měl dělat v něčem jiném než ve Fortranu? Aby s tím měl programátor víc práce?
-
Obecně žádný lepší nemáš. V běžné práci je to nejlepší jazyk.
Co všechno podle tebe ve vývoji softwaru spadá pod "běžnou práci"?
40 až 100 HPP. Prostě obyč vývoj.
Aha, takže výběr technologie pro vývoj softwaru se podle tebe řídí výší mzdy a druhem pracovního poměru vývojáře? A zkoušel jsi s tím vystoupit v kabaretu? Kdybys k tomu přidal zakopávání o vlastní nohy, tak by to mohlo mít úspěch.
-
Troufam si tvrdit, ze Fortran je lepsi nez java...
...napr. pro resice PDE
Dobrá, pokud někdo počítá pořád totéž a má své fortranovské rutiny hotové, tak proč by je nepoužíval dál. Ale technika se vyvíjí, řekl bych, že většina výpočtářů potřebuje svoje modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové.
Pokud někdo potřebuje své modely diferenciálních rovnic aktualizovat, případně tvořit úplně nové, proč by to měl dělat v něčem jiném než ve Fortranu? Aby s tím měl programátor víc práce?
Tak já bych řekl, že většina lidí, co dneska programují ve fortranu nejsou programátoři. Jsou to primárně inženýři, aplikovaní matematici atd.
Pokud někdo potřebuje zásadní aktualizaci rovnic změněného systému, nebo modelovat úplně nový systém, tak já nechápu, proč tu novou práci začínat ve fortranu, když to ve většině M balíků budu mít za 10 % času.
-
OK, tak ještě překlad pro lopaty. Jde o to, že za málo peněz je málo muziky. Takže 40 až 100 na HPP, a třeba 50 až 130 pro podnikatele. Pokud budeš dělat nějaké matematické speciality, tak to určitě nebudeš dělat za lopaťáckých 80 na HPP. Na vše běžné je Java dokonalá.
-
Pokud někdo potřebuje zásadní aktualizaci rovnic změněného systému, nebo modelovat úplně nový systém, tak já nechápu, proč tu novou práci začínat ve fortranu, když to ve většině M balíků budu mít za 10 % času.
Však ty M balíky jsou napsány ve Fortranu a zbytek k nim napíše za těch 10 % času také ve Fortranu. Proč do toho tahat další (a navíc horší) jazyk?
-
Pokud budeš dělat nějaké matematické speciality, tak to určitě nebudeš dělat za lopaťáckých 80 na HPP. Na vše běžné je Java dokonalá.
Tak hlavne v te Jave si muzes napsat UI, ze ktereho pak zavolas Fortran, ktery to spocita. Protoze kdyby to pocitala Java, tak v nekterych pripadech by ses vysledku nemusel dozit.
-
OK, tak ještě překlad pro lopaty. Jde o to, že za málo peněz je málo muziky. Takže 40 až 100 na HPP, a třeba 50 až 130 pro podnikatele. Pokud budeš dělat nějaké matematické speciality, tak to určitě nebudeš dělat za lopaťáckých 80 na HPP. Na vše běžné je Java dokonalá.
A to teda nemůžeš říct rovnou, že Java je podle tebe dokonalý jazyk pro lopaty?
-
Pokud budeš dělat nějaké matematické speciality, tak to určitě nebudeš dělat za lopaťáckých 80 na HPP. Na vše běžné je Java dokonalá.
Tak hlavne v te Jave si muzes napsat UI, ze ktereho pak zavolas Fortran, ktery to spocita. Protoze kdyby to pocitala Java, tak v nekterych pripadech by ses vysledku nemusel dozit.
Což je nesmysl. Java je superrychlá, už jsem to tu myslím psal. Podívej se někdy na nějaké testy. Těžko bys hledal konkurenci.
OK, tak ještě překlad pro lopaty. Jde o to, že za málo peněz je málo muziky. Takže 40 až 100 na HPP, a třeba 50 až 130 pro podnikatele. Pokud budeš dělat nějaké matematické speciality, tak to určitě nebudeš dělat za lopaťáckých 80 na HPP. Na vše běžné je Java dokonalá.
A to teda nemůžeš říct rovnou, že Java je podle tebe dokonalý jazyk pro lopaty?
Pro všechny. I pro lopaty.
-
...
40 až 100 HPP. Prostě obyč vývoj.
Asi nejak starnu, ale zacinam mit problem rozeznavat troly od idiotu.
Někteří prostě zvládají obojí, ;)
-
Což je nesmysl. Java je superrychlá, už jsem to tu myslím psal. Podívej se někdy na nějaké testy. Těžko bys hledal konkurenci.
Když je Java superrychlá, proč potom existují wrappery jako jblas? Nešlo by to v Javě napsat rychlejší?
-
Což je nesmysl. Java je superrychlá, už jsem to tu myslím psal. Podívej se někdy na nějaké testy. Těžko bys hledal konkurenci.
Když je Java superrychlá, proč potom existují wrappery jako jblas? Nešlo by to v Javě napsat rychlejší?
Asi jo, ale proč to přepisovat, když už to je napsané? Kdo to zaplatí?
-
take doporucuji cobol. Moje dcera pracujde u jednoho nejmenovaneho automobiloveho vyrobce a tam maji jeste radu systemu, ktere bezi v cobolu. To oddeleni, kde sedi ti specialiste poziva znacnych vyhod. Napr. je vsude zakazano kourit, ale v tech jejich kancelarich oni klidne kouri a nikdo si jim nedovoli nic rict, protoze bez tech asi 10 starsich panu by se produkce sesypala.
Ale uz i u cobolu to neni co drive. Za mych let se musely datove struktury v cobolu doplnovat (podle ppotreby) o dummy promene velikosti 1 bajtu, protoze celkova velikost muselo byt sude cislo. Ale to pry uz v tech novych verzich neni potreba.
-
Což je nesmysl. Java je superrychlá, už jsem to tu myslím psal. Podívej se někdy na nějaké testy. Těžko bys hledal konkurenci.
Když je Java superrychlá, proč potom existují wrappery jako jblas? Nešlo by to v Javě napsat rychlejší?
Asi jo, ale proč to přepisovat, když už to je napsané? Kdo to zaplatí?
Proč nepoužít některou z existujících alternativ implementovaných v Javě?
-
Třeba je psala lopata a nejsou tak dobré.
-
take doporucuji cobol. Moje dcera pracujde u jednoho nejmenovaneho automobiloveho vyrobce a tam maji jeste radu systemu, ktere bezi v cobolu. To oddeleni, kde sedi ti specialiste poziva znacnych vyhod. Napr. je vsude zakazano kourit, ale v tech jejich kancelarich oni klidne kouri a nikdo si jim nedovoli nic rict, protoze bez tech asi 10 starsich panu by se produkce sesypala.
Ale uz i u cobolu to neni co drive. Za mych let se musely datove struktury v cobolu doplnovat (podle ppotreby) o dummy promene velikosti 1 bajtu, protoze celkova velikost muselo byt sude cislo. Ale to pry uz v tech novych verzich neni potreba.
Třeba Renault na tom má také plno věcí, ale když chceš začít s Cobolem, tak ti dají jak nějaké lopatě. Takže ať si tam kuřáky nechají, když nemají na nové lidi. Zkus nabídnout 150 tisíc juniorům a uvidíš, jak najednou nebude problém mít hromadu nových lidí a pomalé kuřáky můžeš vyhodit.
-
Pokud někdo potřebuje zásadní aktualizaci rovnic změněného systému, nebo modelovat úplně nový systém, tak já nechápu, proč tu novou práci začínat ve fortranu, když to ve většině M balíků budu mít za 10 % času.
Však ty M balíky jsou napsány ve Fortranu a zbytek k nim napíše za těch 10 % času také ve Fortranu. Proč do toho tahat další (a navíc horší) jazyk?
Že jsou M balíky psány ve fortranu neplatí cca od 80. let. Fortran 77 neměl dynamickou alokaci paměti. Bez toho těžko můžete psát univerzální balík s bohatou funkcionalitou. Proto třeba Matlab přepsali v 80. letech do C.
Současné M balíky mají většinou jádro v C. Hodně knihoven mají ve svém jazyce.
Proč do toho tahat další jazyk? To je jako skutečná otázka? Proč asi existují všechny jazyky, které existují? Proč vznikají nové? Asi proto, že se v nich vyvíjí snadněji a levněji než v těch starých.
-
Napr. je vsude zakazano kourit, ale v tech jejich kancelarich oni klidne kouri a nikdo si jim nedovoli nic rict, ...
Sakra, to jsou vyhody. Doufam, ze tam smeji i poustet ghetoblaster na plne koule, chlastat a chodit mesic nemyti.
-
Proč do toho tahat další jazyk? To je jako skutečná otázka? Proč asi existují všechny jazyky, které existují? Proč vznikají nové? Asi proto, že se v nich vyvíjí snadněji a levněji než v těch starých.
Jazyk C byl vyvinut pro tvorbu komponent operačního systému. Jazyk Fortran zase pro vědecké výpočty. Nevidím žádné opodstatnění pro přehazování účelů použití. Fortran se nehodí na operační systémy a C se nehodí na vědecké výpočty.
-
Proč do toho tahat další jazyk? To je jako skutečná otázka? Proč asi existují všechny jazyky, které existují? Proč vznikají nové? Asi proto, že se v nich vyvíjí snadněji a levněji než v těch starých.
Jazyk C byl vyvinut pro tvorbu komponent operačního systému. Jazyk Fortran zase pro vědecké výpočty. Nevidím žádné opodstatnění pro přehazování účelů použití. Fortran se nehodí na operační systémy a C se nehodí na vědecké výpočty.
Kdybych si tvůj nick nevybavoval u celkem rozumných příspěvků, tak bych řekl, že jenom trolluješ.
Jazyk C byl sice vyvinut pro implementaci OS, ale ukázal se být výborným univerzálním jazykem vhodným pro všechno možné.
Vtip je v tom, že zatímto ve fortranu se nedá dělat skoro nic jiného než právě ta matika, tak v C se dá dělat prakticky vše - a i ty věděcké výpočty tam nejdou až tak zásadně hůře, jak by se zdálo ze školních pouček.
IBM-PC byly vyvinuto také jenom jako levná reklama na velké počítačové systémy a dneska se používá se skoro na vše.
Telefony byly vyvinuty na telefonování a dneska si na nich stahuje poštu, posloucháme hudbu, hrajeme hry a občas i koukáme na videa. To je život.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Jinak Kit a trollovat? To nééé :D Nikdy :D
-
Vtip je v tom, že zatímto ve fortranu se nedá dělat skoro nic jiného než právě ta matika, tak v C se dá dělat prakticky vše - a i ty věděcké výpočty tam nejdou až tak zásadně hůře, jak by se zdálo ze školních pouček.
Nějakou dobu jsem ve Fortranu dělal proto mi několik jeho výhod v C chybí. Například v C je vcelku opruz pracovat s polem, všechno musíš dělat po jednotlivých položkách a k tomu povinně indexy od 0. Pokud to chceš jinak, aby sis na to napsal mapování. Zkus třeba v C napsat kopírování jedné matice do druhé bez n-tého řádku a m-tého sloupce. Ve Fortranu je to obyčejné přiřazení. A zkus dělat vědecké výpočty bez komplexních čísel.
I ten Fortran se vyvíjí. Dnes se v něm dá programovat objektově a dynamická alokace datových struktur je už běžnou záležitostí stejně jako GUI. Knihovny jsou uzpůsobeny právě pro potřebu vědců a snadno se používají.
Netvrdím, že by se Fortran měl masově používat místo C, ale v důchodu ještě zdaleka není.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Uz jsem cely nadrzeny na prvni OS napsany v Jave.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Jinak Kit a trollovat? To nééé :D Nikdy :D
Už jsi zjistil, jaké instrukce jsou v prvních 4 bajtech souboru .class a pro který procesor jsou určeny?
-
Tak.... a troll má po ptákách :D SMRT JAVĚ!!! :D :D :D
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Jinak Kit a trollovat? To nééé :D Nikdy :D
Už jsi zjistil, jaké instrukce jsou v prvních 4 bajtech souboru .class a pro který procesor jsou určeny?
Evidentně o Javě moc nevíš, tak se odborníků neptej na blbosti. Já ti jasně naznačil, kde se to používá, ale ty si pořád meleš nějaké svoje nesmysly. Vím, že rád trolluješ jako brácha zboj, ale stejně...
-
Java je nejlepší úplně na všechno. Jen lopata přece dělá jednoduché věci jednoduše, když to jde složitě.
-
Java je nejlepší úplně na všechno. Jen lopata přece dělá jednoduché věci jednoduše, když to jde složitě.
Tak k takovému lopaťáctví se hlásím dobrovolně.
-
Vážně se každá debata musí umlátit lopatama? ???
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Uz jsem cely nadrzeny na prvni OS napsany v Jave.
Android, uz jsi o tom slysel?
Momentalne nejrozsirenejsi OS na tehle planete.
Jo, a krome vlastni Javy to este pouziva nizkourovnovy hardware abstraction layer postaveny na orezanem Linux kernelu + par nativnich nizkourovnovych knihoven napr pro OpenGL.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Uz jsem cely nadrzeny na prvni OS napsany v Jave.
Android, uz jsi o tom slysel?
Momentalne nejrozsirenejsi OS na tehle planete.
Jo, a krome vlastni Javy to este pouziva nizkourovnovy hardware abstraction layer postaveny na orezanem Linux kernelu + par nativnich nizkourovnovych knihoven napr pro OpenGL.
Android je GUI a aplikace, samotný OS pod tím je v C ;-)
-
Java je nejlepší úplně na všechno. Jen lopata přece dělá jednoduché věci jednoduše, když to jde složitě.
A co Occamova břitva? To je moc lopaťácký? :D
-
Když je Java superrychlá, proč potom existují wrappery jako jblas? Nešlo by to v Javě napsat rychlejší?
Výpočet PI v Javě může stejně rychlý jako v C, protože se k tomu nepožívají objekty. Záleží na optimalizačních schopnostech překladače C a JIT v JVM. Totéž platí i o Javascriptu. Teoreticky může v Javě vadit zásobníková instrukční sada, ale to už snad JITy zvládly.
C++ je výkonnější při používání objektů na zásobníku a při vnořování struktur do větších struktur. Obojí je syntaktický cukr a výsledný strojový kód je stejný jako při použití jednoduchých proměnných. Třída v C++ je jen struktura (pro hnidopichy, i s virtuálními metodami je to struktura, jen tam jsou "neviditelné" pointery). Je tedy možné psát esteticky a strukturovaně "zadarmo", tj. bez přidané runtimeové režie.
Vnořování struktur v C++ je jen strukturované pojmenování jednoduchých proměnných v jedné velké struktuře. V Javě takto vnořovat nejde, jde jen vložit pointer na "vnořený" objekt, což není "zadarmo".
Objekty na zásobníku se hodí např. při výpočtech s vektory. V C++ jde napsat třída vektoru s přetíženými operátory a s objekty lze poskládat matematický výraz. Přitom jsou nulové režie na vytváření objektů, stejně jako ve výrazu se skalárními čísly.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Uz jsem cely nadrzeny na prvni OS napsany v Jave.
Android, uz jsi o tom slysel?
Momentalne nejrozsirenejsi OS na tehle planete.
Jo, a krome vlastni Javy to este pouziva nizkourovnovy hardware abstraction layer postaveny na orezanem Linux kernelu + par nativnich nizkourovnovych knihoven napr pro OpenGL.
jaj to preto je taky pomaly a vyzaduje poriadny HW, aby to poriadne slapalo, aj ked to niekedy nestaci.
-
Výpočet PI v Javě může stejně rychlý jako v C, protože se k tomu nepožívají objekty. Záleží na optimalizačních schopnostech překladače C a JIT v JVM. Totéž platí i o Javascriptu. Teoreticky může v Javě vadit zásobníková instrukční sada, ale to už snad JITy zvládly.
http://benchmarksgame.alioth.debian.org/u64q/java.html
pidigits: Java 3.11 sekund, C 1.73 sekund. Máš tam zdrojáky, tak se ukaž, jak to uděláš v Jave stejně rychlé jako v C. Můžeš použít libovolný JIT i JVM.
-
Můžete mi někdo vysvětlit, proč si tu poměřujete penisy, místo aby jste se věnovali OPovo otázce?
-
http://benchmarksgame.alioth.debian.org/u64q/java.html
pidigits: Java 3.11 sekund, C 1.73 sekund. Máš tam zdrojáky, tak se ukaž, jak to uděláš v Jave stejně rychlé jako v C. Můžeš použít libovolný JIT i JVM.
Možná na nějakém JOPu (http://www.jopdesign.com/perf.jsp) poměrně v poho ;-)
Můžete mi někdo vysvětlit, proč si tu poměřujete penisy, místo aby jste se věnovali OPovo otázce?
myslím, že už si z těch odpovědí zde udělal obrázek o tom, co se zde může dozvědět... a buď má jasno, nebo už hledá někde jinde ;-)
-
Odpověď je tady: http://www.root.cz/zpravicky/c-je-nejvyznamnejsim-jazykem-roku-2016-tvrdi-studie-ieee/ ;D
gamer: Zkus to přepsat do Matlabu a hlavně do FORTRANu, ale maximálně F77 nebo radši staršího. Ať zvítězí brutální síla ;-)
-
Já mu v tom jasno udělám - začni v C a zbytek půjde sám. Jenom se vyhni Javě, protože by se taky mohlo stát, že pak budeš muset spolupracovat s tlupou javamanů a to bys asi nedal. Navíc v Javě dnes dělá spousta chytráků, což začíná poněkud snižovat cenu jejich práce. Velký zájem je prý třeba o Ruby, ale mně ten jazyk nějak k srdci nepřirostl (respektive mi nenabídl nic, co bych neudělal v něčem jiném). Případně není špatný do začátku ani ten Python - tak nějak tě automaticky naučí pěkně strukturovat kód :) Každopádně se do začátku pokus vyhnout prostředím pro vývoj, na to budeš mít čas později, syntax highlighting je fajn, ale nějaké automatické doplňování a podobné serepetičky, to je lepší si to ze začátku pěkně vypsat, víc se tím naučíš. Stejně tak bych se vyhnul alespoň pro začátek všemožným frameworkům. Na nějaké vydělávání si programováním minimálně na rok zapomeň a pak se uvidí, jestli to odložíš o další rok, nebo o dva.
-
Odpověď je tady: http://www.root.cz/zpravicky/c-je-nejvyznamnejsim-jazykem-roku-2016-tvrdi-studie-ieee/ ;D
gamer: Zkus to přepsat do Matlabu a hlavně do FORTRANu, ale maximálně F77 nebo radši staršího. Ať zvítězí brutální síla ;-)
Ale odpoved na trochu jinou otazku ;)
Já mu v tom jasno udělám - začni v C a zbytek půjde sám.
Pokud ten zacatek prezijes. C neni dobry jazyk pro vyuku a zacatky. (Coz nemeni nic na tom, ze to je dobry jazyk pro pokrocilejsi pochopeni. Ale to z nej pro zmenu nedela dobry jazyk pro vetsinu vyvoje..)
-
Odpověď je tady: http://www.root.cz/zpravicky/c-je-nejvyznamnejsim-jazykem-roku-2016-tvrdi-studie-ieee/ ;D
Chudák javaman, tomu se asi zhroutí celej svět, až zjistí, že nejlepší jazyk je až na druhém místě za historickou neobjektovou vykopávkou :'( Je mi ho líto :'(
-
Pokud ten zacatek prezijes. C neni dobry jazyk pro vyuku a zacatky. (Coz nemeni nic na tom, ze to je dobry jazyk pro pokrocilejsi pochopeni. Ale to z nej pro zmenu nedela dobry jazyk pro vetsinu vyvoje..)
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
-
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
Nevim, co myslis "klasickymi" jazyky? Imperativni?
Kazdopadne C ma spoustu ostrych hran, ktere proste pro zacatecnika znamenaji dost problemu. Nejjednodussi veci v nem nejsou zdaleka tak snadne jako jinde - uz jen Hello World! neni otazka minuty, ale musis pochopit dost veci. Nemluve o tom, ze je to jazyk kompilovany a pro zacatky je lepsi neco s REPLem. Dale je potreba mentor nebo dobra ucebnice zacatku (Head First, SICP, How to Design Programs...)
Za mne - Python nebo Scheme/Racket. Nebo samozrejme Swift, pokud cloveku nevadi Apple ekosystem. *)
*) urcite to nejsou jedine dobre moznosti. Jenom moznosti (pro zacatky!) o dost lepsi nez C.
-
gamer: Zkus to přepsat do Matlabu a hlavně do FORTRANu, ale maximálně F77 nebo radši staršího. Ať zvítězí brutální síla ;-)
To nemusím dělat, do Fortranu to už přepsali jiní: http://benchmarksgame.alioth.debian.org/u64q/fortran.html
C prostě nelze porazit ;): https://www.youtube.com/watch?v=niO16JEbpWs
-
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
Nevim, co myslis "klasickymi" jazyky? Imperativni?
Kazdopadne C ma spoustu ostrych hran, ktere proste pro zacatecnika znamenaji dost problemu. Nejjednodussi veci v nem nejsou zdaleka tak snadne jako jinde - uz jen Hello World! neni otazka minuty, ale musis pochopit dost veci. Nemluve o tom, ze je to jazyk kompilovany a pro zacatky je lepsi neco s REPLem. Dale je potreba mentor nebo dobra ucebnice zacatku (Head First, SICP, How to Design Programs...)
Za mne - Python nebo Scheme/Racket. Nebo samozrejme Swift, pokud cloveku nevadi Apple ekosystem. *)
*) urcite to nejsou jedine dobre moznosti. Jenom moznosti (pro zacatky!) o dost lepsi nez C.
Swift už běží celkem slušně i na Linuxu. Jinak bych ještě dodal Go, to má k C blízko a je vhodnější pro začátečníky.
-
Swift už běží celkem slušně i na Linuxu. Jinak bych ještě dodal Go, to má k C blízko a je vhodnější pro začátečníky.
Ja vim, ale AFAIK nejsou k dispozici Playgrounds. Ta jsou duvod, proc jsem Swift daval na ten seznam, prestoze k nemu (opet AFAIK) zatim neexistuje vhodna ucebnice.
-
gamer: Zkus to přepsat do Matlabu a hlavně do FORTRANu, ale maximálně F77 nebo radši staršího. Ať zvítězí brutální síla ;-)
To nemusím dělat, do Fortranu to už přepsali jiní: http://benchmarksgame.alioth.debian.org/u64q/fortran.html
C prostě nelze porazit ;): https://www.youtube.com/watch?v=niO16JEbpWs
Hlavne JVM chvilu startuje a rozbieha sa (JIT), C library sa moze ciastocne inlineovat do C (funkcia v .h), parametre je treba kopirovat a prekladat medzi Javou / C, Java musi alokovat native stack.
Jednoznacne plati, ze ked chcete vybornu podporu IDE (refactoring), predvidatelnost, obrovske mnozstvo kniznic a build nastroje (mvnrepository+Maven), tak vyhrava Java s moznym prehodom na Scalu. Tie percenta vykonu sa rychlo dozenu na case vyvoja.
Ked chces rychlost vykonavania alebo chces ist low level, tak vol C.
Na aspon trochu paralelne programy alebo kde by som chcel GC a nechcel by som chaos ako Scalu, tam by som bral Go. Na prototypovanie Python.
-
To nemusím dělat, do Fortranu to už přepsali jiní: http://benchmarksgame.alioth.debian.org/u64q/fortran.html
F90 je Fotran, a ne FORTRAN. Tohle C potře kdykoliv, a Java když má dobrý den >:(
Asi to přepíšu do FIV sám, ale můžu to porovnat akorát s TC v DOSBoxu, a ten nebyl žádný zázrak.
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
OK, to jsme u doslovneho Hello Worldu. Kdyz ale zacnes s retezci (strcat apod.) a obecne s (de)alokaci pameti na heapu, zacne to spravne peklicko. A uzitek z toho minimalni. Predpokladany tazatel (podle me to je klasicky flamebait, nejde o skutecneho zajemce) chce bastit kolace a ne pronikat do podstaty veci.
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
Přezávorkovanost Lispu? Kde jsi o tom slyšel?
Napiš si Hello World v C, potom v Lispu a porovnej počty závorek. Přezávorkovanost v C je podle mne tím pravým peklem.
-
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
Nevim, co myslis "klasickymi" jazyky? Imperativni?
Kazdopadne C ma spoustu ostrych hran, ktere proste pro zacatecnika znamenaji dost problemu. Nejjednodussi veci v nem nejsou zdaleka tak snadne jako jinde - uz jen Hello World! neni otazka minuty, ale musis pochopit dost veci. Nemluve o tom, ze je to jazyk kompilovany a pro zacatky je lepsi neco s REPLem. Dale je potreba mentor nebo dobra ucebnice zacatku (Head First, SICP, How to Design Programs...)
Za mne - Python nebo Scheme/Racket. Nebo samozrejme Swift, pokud cloveku nevadi Apple ekosystem. *)
*) urcite to nejsou jedine dobre moznosti. Jenom moznosti (pro zacatky!) o dost lepsi nez C.
Doví se ze SICP něco o takové základní věci jako hashmapy?
-
Odpověď je tady: http://www.root.cz/zpravicky/c-je-nejvyznamnejsim-jazykem-roku-2016-tvrdi-studie-ieee/ ;D
Chudák javaman, tomu se asi zhroutí celej svět, až zjistí, že nejlepší jazyk je až na druhém místě za historickou neobjektovou vykopávkou :'( Je mi ho líto :'(
Jak bych to asi zjistil? Java je samozřejmě na prvním místě. Nějaký testy lopat (ieee a gamer) mě těžko přesvědčí.
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
Python :D Ten je na naučení prasáren nejlepší. Nezapomeň co nejdřív s monkey patchingem a hned po tom zařaď metaprogramování, protože je cool a strašně moc je to potřeba.
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
Python :D Ten je na naučení prasáren nejlepší. Nezapomeň co nejdřív s monkey patchingem a hned po tom zařaď metaprogramování, protože je cool a strašně moc je to potřeba.
http://www.slideshare.net/PolymathicCoder/the-art-of-metaprogramming-in-java
-
hlavně neplést "nejpopulárnější" a "nejlepší"
-
Doví se ze SICP něco o takové základní věci jako hashmapy?
Ne. Otazka je, zda je to "spatne" nebo "jinak".
-
Já nevím, už mám toho za sebou dost, abych mohl posuzovat jednoduchost pro začátečníky. Ten Python mi přijde jako dobrá volba, jak jsem psal, minimálně to naučí pěkně strukturovat a je pravda, že na první pohled to možná tolik neodradí jako C, ale zase pochopit do začátku proč je tam main, proč jsou tam závorky a proč je tam jeden include, to mi jako katastrofa nepřijde. Oproti tomu mi lispová přezávorkovanost připadá jako peklo.
Python :D Ten je na naučení prasáren nejlepší. Nezapomeň co nejdřív s monkey patchingem a hned po tom zařaď metaprogramování, protože je cool a strašně moc je to potřeba.
http://www.slideshare.net/PolymathicCoder/the-art-of-metaprogramming-in-java
A co jako? Vypadá to snad jako ten v Pythonu?
-
hlavně neplést "nejpopulárnější" a "nejlepší"
Přesně. Nejlepší je, ale popularity asi moc nemá :( Java je na tom stejně jako já :D
-
Doví se ze SICP něco o takové základní věci jako hashmapy?
Ne. Otazka je, zda je to "spatne" nebo "jinak".
Nejsem pedagog, ale jako student bych očekával, že se dovím nejlepší způsob jak řešit konkrétní problém. SICP je zajímavá kniha v tom, že buduje vše od nuly s použitím jen základních konstruktů. Ale někdy by neškodila zmínka, že to jde i lépe.
-
Můžete mi někdo vysvětlit, proč si tu poměřujete penisy, místo aby jste se věnovali OPovo otázce?
1. na otázku bylo již odpovězeno (mimochodem, tvoje odpověď se mi velmi líbila, asi nejlepší zde, je vidět, že je to ze živoat)
2. je to již takový kolorit tady
3. mám dojem, že podobné otázky mají stejně jen za cíl vyvolat další flame
-
C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd.
S C som zacinal nie je to najhorsie.
C je jednoduchy jazyk so zaujimavymi a pritom uplne jednoduchymi featurami (pointery na funkcie), ale pre vyuku ma svoje nevyhody. Napriklad si moze clovek prepisat cast svojej pamate (pole[-1]) a program potom nahodne pada, niekedy iba bez debuggeru, co je pre zaciatocnika menej prinosne ako ArrayOutOfBoundsException alebo iny okamzity pad.
Alebo sa neda spravit vseobecne volanie callbacku s typovo bezpecnym parametrom (fuj void *).
Vlakna su problematicke, pthreads sa tvaria ako kniznica, ale kompilator o nich musi vediet a musi sa im prisposobovat, to dotvara nedefinovany memory model. Iny paralelizmus je problematicky.
C nevedie k objektovemu a ani funkcionalnemu programovaniu.
Umoznuje robit chyby ako tato, co sa chvilu tvari, ze to funguje:
int * ptr_one() {
int a = 1;
...
int *b = &a;
...
return b;
}
C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný.
Pre mna zvyknuteho z pekneho C bolo a stale je C++ a vacsina programov v nom splacany chaos. Podobne pekna ako C bola az na mensie vynimky aj Java, od verzie 8 sa zacala C#-ovatiet. Co nie je explicitne zle, akurat nie je vidiet jasna koncepcia.
C# je podla mna dost odlisny na to, aby sa nedal zvladnut tak v pohode.
-
hlavně neplést "nejpopulárnější" a "nejlepší"
Přesně. Nejlepší je, ale popularity asi moc nemá :( Java je na tom stejně jako já :D
Je debilní a neumí ani setinu z toho, co o sobě tvrdí? No zase tak zlej bych na javu nebyl. Narozdíl od tebe má svoje místo :D
-
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
Nevim, co myslis "klasickymi" jazyky? Imperativni?
Kazdopadne C ma spoustu ostrych hran, ktere proste pro zacatecnika znamenaji dost problemu. Nejjednodussi veci v nem nejsou zdaleka tak snadne jako jinde - uz jen Hello World! neni otazka minuty, ale musis pochopit dost veci. Nemluve o tom, ze je to jazyk kompilovany a pro zacatky je lepsi neco s REPLem. Dale je potreba mentor nebo dobra ucebnice zacatku (Head First, SICP, How to Design Programs...)
Za mne - Python nebo Scheme/Racket. Nebo samozrejme Swift, pokud cloveku nevadi Apple ekosystem. *)
*) urcite to nejsou jedine dobre moznosti. Jenom moznosti (pro zacatky!) o dost lepsi nez C.
Swift už běží celkem slušně i na Linuxu. Jinak bych ještě dodal Go, to má k C blízko a je vhodnější pro začátečníky.
Bohužel, implementace je v žalostném stavu. Například kompilátor Swiftu 3 není schopen přeložit následující výraz
let a: Double = -(1 + 2) + -(3 + 4) + 5
protože v něm je mnoho overloadingu (viz Exponential time complexity in the Swift type checker (http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html)).
Dále Swift 3 obsahuje řadu změn, které nejsou zpětně kompatibilní (viz https://apple.github.io/swift-evolution/). Swift na mě tedy spíše působí, že je stále v nějaké alfa verzi.
-
1. na otázku bylo již odpovězeno (mimochodem, tvoje odpověď se mi velmi líbila, asi nejlepší zde, je vidět, že je to ze živoat)
To bych třeba neřekl. Konkrétně ohledně toho podnikání existuje určitě spousta cest a skoro nikdo se k tomu nevyjádřil.
-
Pak je tu Java, která zvládne všechno a ještě lépe.
Jinak Kit a trollovat? To nééé :D Nikdy :D
Už jsi zjistil, jaké instrukce jsou v prvních 4 bajtech souboru .class a pro který procesor jsou určeny?
No to by mě osobně docela zajímalo, protože jsem si doteď myslel, že je v prvních čtyřech bajtech magic number o hodnotě 0xCAFEBABE (a podobnost s anglickými slovy je zcela záměrná).
-
Už jsi zjistil, jaké instrukce jsou v prvních 4 bajtech souboru .class a pro který procesor jsou určeny?
No to by mě osobně docela zajímalo, protože jsem si doteď myslel, že je v prvních čtyřech bajtech magic number o hodnotě 0xCAFEBABE (a podobnost s anglickými slovy je zcela záměrná).
Ano, tohle je zcela správně. Ještě jsem doufal, že mi javaman napíše, pro který procesor je to určeno.
-
A co to má společného s assemblerem?
-
A co to má společného s assemblerem?
Jakým assemblerem? Bavíme se přece o Javě.
-
Dovolím si nesouhlasit. C je z klasických jazyků asi nejjednodušší, naučí ho programátorsky myslet, tvořit algoritmy atd. C++, C# i Javu už pak zvládne v pohodě, když bude chtít. Nicméně C mu dá celkem nenásilně pocítit i funkci HW, což není do začátku úplně špatný. Ale jestli víš o něčem lepším (kromě Karla), nechám se rád poučit, ono se mi to dobře kecá, když C "používám" (nejsem programátor) již řadu let a ani už nevím, jak jsem k němu přišel.
Nevim, co myslis "klasickymi" jazyky? Imperativni?
Kazdopadne C ma spoustu ostrych hran, ktere proste pro zacatecnika znamenaji dost problemu. Nejjednodussi veci v nem nejsou zdaleka tak snadne jako jinde - uz jen Hello World! neni otazka minuty, ale musis pochopit dost veci. Nemluve o tom, ze je to jazyk kompilovany a pro zacatky je lepsi neco s REPLem. Dale je potreba mentor nebo dobra ucebnice zacatku (Head First, SICP, How to Design Programs...)
Za mne - Python nebo Scheme/Racket. Nebo samozrejme Swift, pokud cloveku nevadi Apple ekosystem. *)
*) urcite to nejsou jedine dobre moznosti. Jenom moznosti (pro zacatky!) o dost lepsi nez C.
Swift už běží celkem slušně i na Linuxu. Jinak bych ještě dodal Go, to má k C blízko a je vhodnější pro začátečníky.
Bohužel, implementace je v žalostném stavu. Například kompilátor Swiftu 3 není schopen přeložit následující výraz
let a: Double = -(1 + 2) + -(3 + 4) + 5
protože v něm je mnoho overloadingu (viz Exponential time complexity in the Swift type checker (http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html)).
Dále Swift 3 obsahuje řadu změn, které nejsou zpětně kompatibilní (viz https://apple.github.io/swift-evolution/). Swift na mě tedy spíše působí, že je stále v nějaké alfa verzi.
Že Swift 3 nebude zpětně kompatibilní autoři upozorňují už přes rok, takže by to nemělo nikoho překvapit. Spíše než překladač by se měla vylepšit standardní knihovna pro Linux.
-
Překvapit asi ne, ale nasere to.
-
placate tu nesmysly. ty vole, to nemate co jinyho na praci? :o
-
placate tu nesmysly. ty vole, to nemate co jinyho na praci? :o
No ty vole, tak neplácej s náma a nahoď něco inteligentního :D Uvědom si životní cyklus diskuzí na Rootu:
1. Je položena otázka
2. Jarda k tomu hodí vtipné vyjádření, sice k věci, ale odpověď to není
3. První vlna OT - skalní trollové - otázka se pomluví, z tazatele se udělá idiot, žádná odpověď
4. Nějaká odpověď
5. Druhá vlna OT - opět skalní trollové - odpověď se pomluví, z odpovídajícího se udělá idiot, lepší odpověď se neobjeví
6. Pár dalších odpovědí, případně jejich upřesnění
7. Trollí všichni (ale k tématu), přeměřují přirození, dělají ze sebe idioty navzájem
8. Poslední vlna OT - trolling je přesměrován zcela na OT, řeší se uprchlíci, iSalámisti, systemd, základní otázka života, vesmíru a vůbec, pan Nový vysvětluje dokonalost světa a jeho schopnost autoregulace
9. Všichni už jsou oficiálně idioti a diskuse pomalu umírá a přesouvá se k dalšímu vláknu
-
...
10. Objeví se někdo, kdo se pozastaví nad plácáním nesmyslů, ale opět žádná odpověď.
11. Dostane na to několik reakcí, které také neobsahují odpověď na původní dotaz, pouze tomu trollovi nějak vtipně odpoví v devíti bodech, ke kterým se následně přidávají další.
-
Až na bod 8. ... p. Nový vysvětluje... P. Nový nic nevysvětluje, jen recituje naučené básničky. Něco jak Klaus.
-
Až na bod 8. ... p. Nový vysvětluje... P. Nový nic nevysvětluje, jen recituje naučené básničky. Něco jak Klaus.
No občas to vypadá, že je to trochu mimo, ale podle mě je to celkem příjemné zpestření diskuzí. S čí je to hlavy je mi celkem jedno, ale baví mě to :)
Jen pro upřesnění, nechtěl jsem se pana Nového nějak negativně dotknout jeho uvedením v seznamu, naopak to je jeden z těch lepších bodů a tímto mu za to děkuji :)
-
placate tu nesmysly. ty vole, to nemate co jinyho na praci? :o
No ty vole, tak neplácej s náma a nahoď něco inteligentního :D Uvědom si životní cyklus diskuzí na Rootu:
1. Je položena otázka
2. Jarda k tomu hodí vtipné vyjádření, sice k věci, ale odpověď to není
3. První vlna OT - skalní trollové - otázka se pomluví, z tazatele se udělá idiot, žádná odpověď
4. Nějaká odpověď
5. Druhá vlna OT - opět skalní trollové - odpověď se pomluví, z odpovídajícího se udělá idiot, lepší odpověď se neobjeví
6. Pár dalších odpovědí, případně jejich upřesnění
7. Trollí všichni (ale k tématu), přeměřují přirození, dělají ze sebe idioty navzájem
8. Poslední vlna OT - trolling je přesměrován zcela na OT, řeší se uprchlíci, iSalámisti, systemd, základní otázka života, vesmíru a vůbec, pan Nový vysvětluje dokonalost světa a jeho schopnost autoregulace
9. Všichni už jsou oficiálně idioti a diskuse pomalu umírá a přesouvá se k dalšímu vláknu
Děkuji za vylepšení dnešního dne. :D
-
;D Něco na tom bude.
-
celkom pekna matica:
http://sijinjoseph.com/programmer-competency-matrix/ (http://sijinjoseph.com/programmer-competency-matrix/)
PS: javaman, mozes si to pozriet a zaradit sa, kam patris :)
-
Kam asi. Nějaký lopaťácký první levely jsem přeskočil už na střední.
-
Kam asi. Nějaký lopaťácký první levely jsem přeskočil už na střední.
A já myslel, že jsi pro jistotu přeskočil všechny levely.
-
Ty poslední jsou dobrej start.
-
Ty poslední jsou dobrej start.
Ta 4. uroven v asi petine nebo desetine pripadu hovori o zverejnenem, nekdy i siroce pouzivanem kusu SW, API, atd. Mohl bys slevit ze skromnosti a hodit sem par url svejch vysledku?
-
Kam asi. Nějaký lopaťácký první levely jsem přeskočil už na střední.
A já myslel, že jsi pro jistotu přeskočil všechny levely.
;D ;D ;D :D :D
-
Až na bod 8. ... p. Nový vysvětluje... P. Nový nic nevysvětluje, jen recituje naučené básničky. Něco jak Klaus.
No občas to vypadá, že je to trochu mimo, ale podle mě je to celkem příjemné zpestření diskuzí. S čí je to hlavy je mi celkem jedno, ale baví mě to :)
Jen pro upřesnění, nechtěl jsem se pana Nového nějak negativně dotknout jeho uvedením v seznamu, naopak to je jeden z těch lepších bodů a tímto mu za to děkuji :)
+1. Novy je magor, ale spravnym smerem. Jeho prispevky jsou na pomezi libertarianstvi a sci-fi a pro oboje mam slabost, abyste vedeli. Bod 9. rekurzivne naplnen.
-
+1. Novy je magor, ale spravnym smerem. Jeho prispevky jsou na pomezi libertarianstvi a sci-fi a pro oboje mam slabost, abyste vedeli. Bod 9. rekurzivne naplnen.
Ja mam popravde v posledni dobe radeji chytre lidi, co maji opacne nazory, nez magory typu Novotny, kteri maji nazory podobne :/
-
+1. Novy je magor, ale spravnym smerem. Jeho prispevky jsou na pomezi libertarianstvi a sci-fi a pro oboje mam slabost, abyste vedeli. Bod 9. rekurzivne naplnen.
Ja mam popravde v posledni dobe radeji chytre lidi, co maji opacne nazory, nez magory typu Novotny, kteri maji nazory podobne :/
Myslis komunisty?
-
Jak souvisí inteligence s politickou orientací?
-
Dost výrazně: http://www.national-geographic.cz/clanky/volici-pravice-jsou-hloupejsi-nez-volici-levice-tvrdi-to-kanadska-studie.html
-
ROFL. Nevím, jestli jsi četl jen titulek, ale ta studie je sračka. Nebo ten článek, nevím.
-
Tohle je oblíbená strategie jak získat voliče, kteří se chtějí zařadit mezi ty "chytřejší". Výsledek studie vyjde pozitivně pro toho, kdo jí zaplatil. Takovéhle průzkumy IMHO do demokracie nepatří.
-
Dost výrazně: http://www.national-geographic.cz/clanky/volici-pravice-jsou-hloupejsi-nez-volici-levice-tvrdi-to-kanadska-studie.html
Jojo, protože konzervativní přece znamená pravice. Třeba v Praze jsou baštami intelektu sídliště, protože se tam nejvíc volí socani.
-
Dost výrazně: http://www.national-geographic.cz/clanky/volici-pravice-jsou-hloupejsi-nez-volici-levice-tvrdi-to-kanadska-studie.html
Jojo, protože konzervativní přece znamená pravice. Třeba v Praze jsou baštami intelektu sídliště, protože se tam nejvíc volí socani.
Škatulkujete stejně jako ta studie, jen z opačné strany.
-
Tohle je oblíbená strategie jak získat voliče, kteří se chtějí zařadit mezi ty "chytřejší". Výsledek studie vyjde pozitivně pro toho, kdo jí zaplatil. Takovéhle průzkumy IMHO do demokracie nepatří.
Přesně, správná demokracie vše schovává. Studie, že programování se může věnovat jen pár procent populace, je také špatná? Že na to většina lidí nemá, protože jsou to blbci, to nevadí a do správné demokracie nepatří! :D
-
ROFL. Nevím, jestli jsi četl jen titulek, ale ta studie je sračka. Nebo ten článek, nevím.
Je to sračka, protože se neshoduje s tvými předsudky? Právě předsudkům se také věnuje ;-)
-
OMG. Je to sračka, protože je to sračka. Nic tam není a jen titulek říká, že něco s něčím souvisí, ale není tam vysvětlení a lopaty na to hned skočí. Politické přesvědčení a inteligence nemá jak souviset.
-
ROFL. Nevím, jestli jsi četl jen titulek, ale ta studie je sračka. Nebo ten článek, nevím.
Je to sračka, protože se neshoduje s tvými předsudky? Právě předsudkům se také věnuje ;-)
Je to sračka, protože pokládá rovnost mezi pravici a konzervativmus. Jsem podle článku pravičák, pokud: nemám rád arbitrární pravidla stanovená třetí stranou, jsem individualista, preferuji osobní zodpovědnost a pokládám koncepty ekonomické svobody, svobody slova a dobrovolnosti za vysoce důležité?
-
ROFL. Nevím, jestli jsi četl jen titulek, ale ta studie je sračka. Nebo ten článek, nevím.
Je to sračka, protože se neshoduje s tvými předsudky? Právě předsudkům se také věnuje ;-)
Je to sračka, protože pokládá rovnost mezi pravici a konzervativmus. Jsem podle článku pravičák, pokud: nemám rád arbitrární pravidla stanovená třetí stranou, jsem individualista, preferuji osobní zodpovědnost a pokládám koncepty ekonomické svobody, svobody slova a dobrovolnosti za vysoce důležité?
Celé je to blbost. Například Larry Wall a Yukihiro Matsumoto jsou konzervativní křesťané. Hlupáci to rozhodně nejsou. Politická orientace nesouvisí s inteligencí. Každý máme v životě jiné priority a podle toho volíme.
-
Je to sračka, protože je to sračka.
Tento argument je sračka.
-
Konzervstivizmus je socializmom burzoazneho establismentu.
Jedina skutocna pravica je libertarianizmus.
-
Co kdybychom se od politiky vrátili k Lispu, jako nejlepšímu programovacímu jazyku vůbec?
-
Konzervstivizmus je socializmom burzoazneho establismentu.
Jedina skutocna pravica je libertarianizmus.
Kdyby měl buržoazní establišment dodržovat desatero, tak si svých peněz moc neužije. Jde jim jen o to, aby lůza nezatoužila po statku bližního svého.
-
Až na bod 8. ... p. Nový vysvětluje... P. Nový nic nevysvětluje, jen recituje naučené básničky. Něco jak Klaus.
Abych vám přiblížil můj pracovní postup, jen popisuji model světa, který jsem si vytvořil. Názor o jeho platnosti si už musíte udělat sám. A v životě jsem nečetl ani jednu ekonomickou knihu, pokud se v některých ohledech s některými shoduji, znamená to, že jsme nezávisle došli k podobnému modelu reality :-))) S ekonomií je to podobné jako s programováním, než se hrabat v cizím kódu, kolikrát je rychlejší napsat vlastní :-)))
-
IN - občas by sis měl něco přečíst ať zbytečně nevymejšlíš již vymyšlený a ještě si myslíš, s jakou úžasnou novinkou jsi to přišel.
Pro ostatní - co to tady kurwa melete za sr*čky?
-
IN - občas by sis měl něco přečíst ať zbytečně nevymejšlíš již vymyšlený a ještě si myslíš, s jakou úžasnou novinkou jsi to přišel.
Pro ostatní - co to tady kurwa melete za sr*čky?
Já si tedy spíš myslel, že je to blbost, a vidíte, prý to byla cesta k funkčnímu řešení, což mě těší :-)
Chcete-li být kreativní, nesmíte se bát být směšný. Směšnost je totiž funkce, která vás má udržet na "feromonové stopě" vybraného řešení, proto je třeba překonat určitou bariéru, kterou překoná jen někdo, aby mohl najít i jiný směr. Často to končí nesmyslem, ale to přece nevadí, trh si to přebere.
Je to něco o čem píše Robert Musil v Muži bez vlastností, kde píše o smyslu pro možnost :-)
-
Chcete-li být kreativní, nesmíte se bát být směšný. Směšnost je totiž funkce, která vás má udržet na "feromonové stopě" vybraného řešení, proto je třeba překonat určitou bariéru, kterou překoná jen někdo, aby mohl najít i jiný směr. Často to končí nesmyslem, ale to přece nevadí, trh si to přebere.
Je to něco o čem píše Robert Musil v Muži bez vlastností, kde píše o smyslu pro možnost :-)
Tohle se mi líbí. Vždy, když se mi tu někdo směje kvůli nějakému mému výroku, si uvědomím, že jsem na cestě, které se ten posměváček bojí.
-
Pro ostatní - co to tady kurwa melete za sr*čky?
Já jim to říkám pořád :D
Chcete-li být kreativní, nesmíte se bát být směšný. Směšnost je totiž funkce, která vás má udržet na "feromonové stopě" vybraného řešení, proto je třeba překonat určitou bariéru, kterou překoná jen někdo, aby mohl najít i jiný směr. Často to končí nesmyslem, ale to přece nevadí, trh si to přebere.
Je to něco o čem píše Robert Musil v Muži bez vlastností, kde píše o smyslu pro možnost :-)
Tohle se mi líbí. Vždy, když se mi tu někdo směje kvůli nějakému mému výroku, si uvědomím, že jsem na cestě, které se ten posměváček bojí.
Pokud je někdo hloupý a drží a se přečtených cest, které nedávají smysl, tak bych tam moc možností neviděl. Na druhou stranu mít kreativitu bez logiky je také možnost. Můžeš vymýšlet plno věcí, včetně úplných píčoviny, ale nikdy nevíš, která z toho je dobrá. Tam už bych cestu viděl.
-
Nový - jeden o voze, druhej o koze. Což je u Novýho obvyklé.
-
Jednoznacne c. Podsunuta podotazka o vydelku a uplatneni s tim samozrejme souvisi, ale je to o cloveku - jestli chce byt nekomu prospesny, je-li altruista a spousty dalsiho. Ceckem se da napsat prakticky vsechno, i vyssi jazyk atd. Takze guru programatorovi staci perfektni znalost c, samozrejme vcetne jeho zdrojaku a nikdo na nej nema.
-
Že nesežene žádnou práci, to je vedlejší, co? :D Nevím, jestli si viděl mzdy u C, ale pokud bys chtěl 180 jako ten tvůj modelový týpek, tak celkem rychle zjistí, že nejlepší je nepracovat vůbec.
-
Chcete-li být kreativní, nesmíte se bát být směšný. Směšnost je totiž funkce, která vás má udržet na "feromonové stopě" vybraného řešení, proto je třeba překonat určitou bariéru, kterou překoná jen někdo, aby mohl najít i jiný směr. Často to končí nesmyslem, ale to přece nevadí, trh si to přebere.
Je to něco o čem píše Robert Musil v Muži bez vlastností, kde píše o smyslu pro možnost :-)
Tohle se mi líbí. Vždy, když se mi tu někdo směje kvůli nějakému mému výroku, si uvědomím, že jsem na cestě, které se ten posměváček bojí.
Pokud je někdo hloupý a drží a se přečtených cest, které nedávají smysl, tak bych tam moc možností neviděl. Na druhou stranu mít kreativitu bez logiky je také možnost. Můžeš vymýšlet plno věcí, včetně úplných píčoviny, ale nikdy nevíš, která z toho je dobrá. Tam už bych cestu viděl.
No právě. Když vidím, jak se ostatní drží přečtených cest, které nedávají smysl a vesele se přitom plácají po zádech, tak mi nezbývá, než jít vlastní cestou. Když ji tady popíši, tak ti, kterým se to líbí, zpravidla mlčí a ti, kterým se to nelíbí, bučí.
-
Že nesežene žádnou práci, to je vedlejší, co? :D Nevím, jestli si viděl mzdy u C, ale pokud bys chtěl 180 jako ten tvůj modelový týpek, tak celkem rychle zjistí, že nejlepší je nepracovat vůbec.
Pokud bude hlavnim kriteriem vyse kompenzace, doporucoval bych ABAP a zahakovat treba v CEZu nebo jinym korporatu. Akorat se z toho clovek asi brzo pobleje nebo se ufetuje kokesem.
-
No právě. Když vidím, jak se ostatní drží přečtených cest, které nedávají smysl a vesele se přitom plácají po zádech, tak mi nezbývá, než jít vlastní cestou. Když ji tady popíši, tak ti, kterým se to líbí, zpravidla mlčí a ti, kterým se to nelíbí, bučí.
Vlastní cestou? Tak proč sem většinou posíláš cizí cesty? Typicky dávat mezery do metod je správné, ale podle tebe to v Clean code zatracují. Logicky je výhoda mít mezery v metodách a nepotřebuješ k tomu žádné knížky.
Že nesežene žádnou práci, to je vedlejší, co? :D Nevím, jestli si viděl mzdy u C, ale pokud bys chtěl 180 jako ten tvůj modelový týpek, tak celkem rychle zjistí, že nejlepší je nepracovat vůbec.
Pokud bude hlavnim kriteriem vyse kompenzace, doporucoval bych ABAP a zahakovat treba v CEZu nebo jinym korporatu. Akorat se z toho clovek asi brzo pobleje nebo se ufetuje kokesem.
Hlavní kritérium je C za normální peníze. Takže tak 120+. Jenže ty nenajdeš práci často ani za 80.
-
No právě. Když vidím, jak se ostatní drží přečtených cest, které nedávají smysl a vesele se přitom plácají po zádech, tak mi nezbývá, než jít vlastní cestou. Když ji tady popíši, tak ti, kterým se to líbí, zpravidla mlčí a ti, kterým se to nelíbí, bučí.
Vlastní cestou? Tak proč sem většinou posíláš cizí cesty? Typicky dávat mezery do metod je správné, ale podle tebe to v Clean code zatracují. Logicky je výhoda mít mezery v metodách a nepotřebuješ k tomu žádné knížky.
Aha, takže ty jdeš vlastní cestou, protože jsi přesvědčen, že dávat prázdné řádky do metod je správné. Mně to nevadí, klidně si tak programuj. Jen v tom nevidím žádnou logiku.
Mezery do metod samozřejmě patří, jinak by se nám slily identifikátory s klíčovými slovy a program by nešel ani přeložit. Výjimkou je Fortran, který všechny mezery ignoruje a je tedy jedno, zda tam nějaké máš.
-
To není vlastní cesta, to je logika programování. Vlastní cestou jdeš ty, ale asi tě moc lidí následovat nebude. Třeba jen nemáš cit pro programování, takže ti přijde všechno hnusně zkomprimované v pořádku.
Přesně tak, prázdné řádky jsou fajn.
-
Pro ostatní - co to tady kurwa melete za sr*čky?
Já jim to říkám pořád :D
Chcete-li být kreativní, nesmíte se bát být směšný. Směšnost je totiž funkce, která vás má udržet na "feromonové stopě" vybraného řešení, proto je třeba překonat určitou bariéru, kterou překoná jen někdo, aby mohl najít i jiný směr. Často to končí nesmyslem, ale to přece nevadí, trh si to přebere.
Je to něco o čem píše Robert Musil v Muži bez vlastností, kde píše o smyslu pro možnost :-)
Tohle se mi líbí. Vždy, když se mi tu někdo směje kvůli nějakému mému výroku, si uvědomím, že jsem na cestě, které se ten posměváček bojí.
Pokud je někdo hloupý a drží a se přečtených cest, které nedávají smysl, tak bych tam moc možností neviděl. Na druhou stranu mít kreativitu bez logiky je také možnost. Můžeš vymýšlet plno věcí, včetně úplných píčoviny, ale nikdy nevíš, která z toho je dobrá. Tam už bych cestu viděl.
To ale nevíte nikdy, vždy o tom rozhodne trh, tedy rozhodne to, jak ostatní potřebují vaše řešení. Svět je dokonalý.
-
hele javamene - zajimalo by me kdy stihas programovat kdyz travis 3/4 zivota psanim debilit na fora ...
-
To není vlastní cesta, to je logika programování. Vlastní cestou jdeš ty, ale asi tě moc lidí následovat nebude. Třeba jen nemáš cit pro programování, takže ti přijde všechno hnusně zkomprimované v pořádku.
Přesně tak, prázdné řádky jsou fajn.
Jdu vlastní cestou, pokud se řídím radami jednoho z nejprestižnějších mentorů?
Aby bylo jasno: Nic nemám hnusně zkomprimováno. Můj kód je velmi snadno čitelný. Krátké řádky, jednoduché a výstižné názvy proměnných a metod, krátký seznam formálních parametrů, krátké metody. Čistý kód.
-
To není vlastní cesta, to je logika programování. Vlastní cestou jdeš ty, ale asi tě moc lidí následovat nebude. Třeba jen nemáš cit pro programování, takže ti přijde všechno hnusně zkomprimované v pořádku.
Přesně tak, prázdné řádky jsou fajn.
Jdu vlastní cestou, pokud se řídím radami jednoho z nejprestižnějších mentorů?
Aby bylo jasno: Nic nemám hnusně zkomprimováno. Můj kód je velmi snadno čitelný. Krátké řádky, jednoduché a výstižné názvy proměnných a metod, krátký seznam formálních parametrů, krátké metody. Čistý kód.
Jestli je vás víc, kdo neumí programovat, tak asi není tvoje, no. Ale o tom už jsem psal, že pokud někdo radí blbosti a ty to následuješ, tak to není úplně ono. Hlavně jsi před chílí reagoval, že právě ty to neděláš, tak nevím.
Pokud ti v metodách chybí mezery, tak to bude asi pěkný hnus na poblití.
hele javamene - zajimalo by me kdy stihas programovat kdyz travis 3/4 zivota psanim debilit na fora ...
No, neni to jednoduchý, ale když jsi tak dobrý jako já, tak to dáš.
-
Hele, tady prima džob:
http://www.itnetwork.cz/programator-nabidka-prace-v-it/detail/234
Logistická aplikace hledá PHPkáře. Uděláš mě?
Zadavatel
Jiřina Krásná
Tak pokud je opravdu K/k-rásná, tak bych ji klidně udělal... :P
-
Pokud ti v metodách chybí mezery, tak to bude asi pěkný hnus na poblití.
Mýlíš se. V metodách mi žádné mezery nechybí.
-
hele javamene - zajimalo by me kdy stihas programovat kdyz travis 3/4 zivota psanim debilit na fora ...
No, neni to jednoduchý, ale když jsi tak dobrý jako já, tak to dáš.
[/quote]
aaa - tak pan je troll a idiot v jednom :) uz to chapu :)
-
Myslím, že to chápeš špatně.
-
Vlastní cestou? Tak proč sem většinou posíláš cizí cesty? Typicky dávat mezery do metod je správné, ale podle tebe to v Clean code zatracují. Logicky je výhoda mít mezery v metodách a nepotřebuješ k tomu žádné knížky.
Dělej si se svými metodami co chceš, clean code nezná konkrétní případy, clean code například tvrdí, že komentáře jsou zbytečné, protože čistý kód je samodeskriptivní. Každopádně, pokud tvoříš metody s deskriptivním názvem, nerveš do nich 150 funkcionalit najednou a umíš kód dobře strukturovat, tak VĚTŠINOU jsou prázdné řádky i komentáře zbytečné. Pokud v kódu potřebuješ cokoliv oddělit prázdným řádkem, nebo i okomentovat, je k zamyšlení, jestli danou část kódu nevyčlenit do a místo komentu jí dát vhodný název. Je to jedno z dobrých kritérií, který ti pomůžou psát čitelnější kód.
Jinak doporučuji v nicku místo (ten nejlepší) používat (neberte mě vážně), aby náhodou někdo nezačal ty tvoje kecy opravdu používat a nevznikla další neschopná lopata tvého formátu.
-
Vlastní cestou? Tak proč sem většinou posíláš cizí cesty? Typicky dávat mezery do metod je správné, ale podle tebe to v Clean code zatracují. Logicky je výhoda mít mezery v metodách a nepotřebuješ k tomu žádné knížky.
Dělej si se svými metodami co chceš, clean code nezná konkrétní případy, clean code například tvrdí, že komentáře jsou zbytečné, protože čistý kód je samodeskriptivní. Každopádně, pokud tvoříš metody s deskriptivním názvem, nerveš do nich 150 funkcionalit najednou a umíš kód dobře strukturovat, tak VĚTŠINOU jsou prázdné řádky i komentáře zbytečné. Pokud v kódu potřebuješ cokoliv oddělit prázdným řádkem, nebo i okomentovat, je k zamyšlení, jestli danou část kódu nevyčlenit do a místo komentu jí dát vhodný název. Je to jedno z dobrých kritérií, který ti pomůžou psát čitelnější kód.
Jinak doporučuji v nicku místo (ten nejlepší) používat (neberte mě vážně), aby náhodou někdo nezačal ty tvoje kecy opravdu používat a nevznikla další neschopná lopata tvého formátu.
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
-
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
Povídej, čemu jsi nerozuměl? Co je na tom pro tebe originálního?
-
Stejně je to jedno, vše začalo a skončí s Céčkem.
-
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
Povídej, čemu jsi nerozuměl? Co je na tom pro tebe originálního?
Ty jsi tu originálnost v tom nenašel? Jsem jedinej na celým světě, kdo to tak dělá. A jsem nejvíc nejlepší, lepší než javaman. A to už je co říct :D
-
Ty jsi tu originálnost v tom nenašel? Jsem jedinej na celým světě, kdo to tak dělá. A jsem nejvíc nejlepší, lepší než javaman. A to už je co říct :D
Tak moment, když jsme dva (s Bobem tři), tak už to zas tak originální není.
Jistě, mám ke Clean Code určité výhrady, ale moc jich není.
-
Ty jsi tu originálnost v tom nenašel? Jsem jedinej na celým světě, kdo to tak dělá. A jsem nejvíc nejlepší, lepší než javaman. A to už je co říct :D
Tak moment, když jsme dva (s Bobem tři), tak už to zas tak originální není.
Jistě, mám ke Clean Code určité výhrady, ale moc jich není.
Já jich taky pár mám, ale já nejsem programátor, tak mi to většinou nevadí. Ale většinou se za svoje dílo stydím, když to musím někomu dát :D
-
Ty jsi tu originálnost v tom nenašel? Jsem jedinej na celým světě, kdo to tak dělá. A jsem nejvíc nejlepší, lepší než javaman. A to už je co říct :D
Tak moment, když jsme dva (s Bobem tři), tak už to zas tak originální není.
Jistě, mám ke Clean Code určité výhrady, ale moc jich není.
Já jich taky pár mám, ale já nejsem programátor, tak mi to většinou nevadí. Ale většinou se za svoje dílo stydím, když to musím někomu dát :D
Přesně, nějakej patlal v patnáci jazycích do toho nemůže vidět.
-
Ty jsi tu originálnost v tom nenašel? Jsem jedinej na celým světě, kdo to tak dělá. A jsem nejvíc nejlepší, lepší než javaman. A to už je co říct :D
Tak moment, když jsme dva (s Bobem tři), tak už to zas tak originální není.
Jistě, mám ke Clean Code určité výhrady, ale moc jich není.
Tři lopaty na světě nic moc neovlivní. To se pořád dá brát jako originálnost ;)
-
Jistě, mám ke Clean Code určité výhrady, ale moc jich není.
Já jich taky pár mám, ale já nejsem programátor, tak mi to většinou nevadí. Ale většinou se za svoje dílo stydím, když to musím někomu dát :D
Povídej. Za mne je to omezení délky řádku na 120 znaků. Mně stačí 80 a ještě s rezervou. Možná to souvisí s délkou názvů identifikátorů, kde Bob doporučuje slepeninu z více slov. Je to dáno vlastnostmi germánských jazyků. Obvykle si však vystačím s jedním slovem. Samozřejmě bez zkratek.
-
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
Povídej, čemu jsi nerozuměl? Co je na tom pro tebe originálního?
Proč myslíš, že jsem něčemu nerozuměl? Spíš to vypadá, že to ty jsi nepochopil, o čem vlastně je ten epigram.
-
No, neni to jednoduchý, ale když jsi tak dobrý jako já, tak to dáš.
Ty nie si dobry, lebo by si dokazal vyriesit ulohu, ktoru som ti zadal. A predstav si, nevyriesi to hocikto, keby si sa obranoval tym, ze to je pre lopaty. ty ani programovat nevies, len trollujes 8)
-
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
Povídej, čemu jsi nerozuměl? Co je na tom pro tebe originálního?
Proč myslíš, že jsem něčemu nerozuměl? Spíš to vypadá, že to ty jsi nepochopil, o čem vlastně je ten epigram.
Ten epigram mi prostě vyčítá, proč jdu po mostě, když se ostatní brodí louží.
-
No, neni to jednoduchý, ale když jsi tak dobrý jako já, tak to dáš.
Ty nie si dobry, lebo by si dokazal vyriesit ulohu, ktoru som ti zadal. A predstav si, nevyriesi to hocikto, keby si sa obranoval tym, ze to je pre lopaty. ty ani programovat nevies, len trollujes 8)
To mě nepřekvapuje, že to běžný lopaty nedaj. Ty neuměj vůbec nic. Bych chtěl žít v tvém pohádkovém světě, kde Kit a Tuxik jsou dobří programátoři a já nic neumím. Ale bohužel, je to jen fantazie...
-
Hm, tyhle praktiky mi připomínají Havlíčkův epigram Originálnost.
Povídej, čemu jsi nerozuměl? Co je na tom pro tebe originálního?
Proč myslíš, že jsem něčemu nerozuměl? Spíš to vypadá, že to ty jsi nepochopil, o čem vlastně je ten epigram.
Ten epigram mi prostě vyčítá, proč jdu po mostě, když se ostatní brodí louží.
Takže jsi to opravdu nepochopil.
-
Bacha na pusu, bavíš se tu o Kitovi! Ten, který místo IDE "programuje" ve Vimu a rozhodně žádné prázdné řádky do metod nedává. Ten přece chápe všechno a kdyby něco ne, tak brácha zboj pomůže! :D
-
Povídej. Za mne je to omezení délky řádku na 120 znaků. Mně stačí 80 a ještě s rezervou. Možná to souvisí s délkou názvů identifikátorů, kde Bob doporučuje slepeninu z více slov. Je to dáno vlastnostmi germánských jazyků. Obvykle si však vystačím s jedním slovem. Samozřejmě bez zkratek.
Největší problém mám s 20ti řádky na metodu. Vim o tom, že občas i zbytečně něco rozepisuju na víc řádků, když se mi to zdá přehlednější a občas to prostě tak nějak vyplyne samo a nechce se mi dělit něco, co k sobě logicky patří a co považuji za jeden krok, na víc částí. I ty komentáře jsou občas sporný, osobně je používám tam, kde jsem musel něco moc vymýšlet a vím, že za chvíli nebudu vědět, proč jsem to tak udělal. Mám tím potom krásně označená místa, kde jsem to dělal moc složitě a je to dobrý začátek při případném refaktoringu :D Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil". :D
-
No, neni to jednoduchý, ale když jsi tak dobrý jako já, tak to dáš.
Ty nie si dobry, lebo by si dokazal vyriesit ulohu, ktoru som ti zadal. A predstav si, nevyriesi to hocikto, keby si sa obranoval tym, ze to je pre lopaty. ty ani programovat nevies, len trollujes 8)
To mě nepřekvapuje, že to běžný lopaty nedaj. Ty neuměj vůbec nic. Bych chtěl žít v tvém pohádkovém světě, kde Kit a Tuxik jsou dobří programátoři a já nic neumím. Ale bohužel, je to jen fantazie...
Tak to pozor, já nikdy nenapsal, že jsem dobrej programátor, protože prostě nejsem programátor, což mi ovšem nebrání v tom, si občas něco naprogramovat. Nicméně vím s jistotou, že jsem v programování o několik řádů lepší než ty (což není tak těžký, to je i moje malá dcera a vlastně asi i můj pes).
-
Přesně, nějakej patlal v patnáci jazycích do toho nemůže vidět.
Musím tě zklamat, ale aktivně používám jen C, Perl, Python, ABAP, PHP a jestli se to dá vůbec považovat za jazyky, tak Bash a HTML + okolní bordel - JS, CSS. V minulosti jsem dělal hodně v ASM a na škole v TP.
To jsem jen na 11, když se hodně snažím. Ale jinak kdybych měl započítat každej jazyk, ve kterým už jsem byl něco nucenej udělat, nebo alespoň upravit, tak jsi mě zase dost podcenil, protože bych musel přihodit C++, C#, Java, COBOL, Fortran, LISP a jeho několik odvozenin, Ruby, Delphi, Basic v mnoha variantách včetně Visual, DOSOvý BAŤáky a samozřejmě můj oblíbenec - Karel. A to jsem určitě na něco zapomněl. A ne, opravdu si všechno nepamatuju, ale kupodivu jsem schopnej se za relativně krátkou dobu zorientovat téměř v čemkoliv, co se mi dostane do ruky.
-
Povídej. Za mne je to omezení délky řádku na 120 znaků. Mně stačí 80 a ještě s rezervou. Možná to souvisí s délkou názvů identifikátorů, kde Bob doporučuje slepeninu z více slov. Je to dáno vlastnostmi germánských jazyků. Obvykle si však vystačím s jedním slovem. Samozřejmě bez zkratek.
Největší problém mám s 20ti řádky na metodu. Vim o tom, že občas i zbytečně něco rozepisuju na víc řádků, když se mi to zdá přehlednější a občas to prostě tak nějak vyplyne samo a nechce se mi dělit něco, co k sobě logicky patří a co považuji za jeden krok, na víc částí. I ty komentáře jsou občas sporný, osobně je používám tam, kde jsem musel něco moc vymýšlet a vím, že za chvíli nebudu vědět, proč jsem to tak udělal. Mám tím potom krásně označená místa, kde jsem to dělal moc složitě a je to dobrý začátek při případném refaktoringu :D Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil". :D
Tak s tímto pravidlem bych si hlavu nelámal, zejména pokud účelně výrazy rozděluješ na více řádek. Také to tak dělám. Když metoda vyjde na 30 řádek, tak je to stále OK, to číslo je prostě "měkké". Pokud se ti nějaká metoda jeví dlouhá, vyber si z ní nějaký scope, zamysli se nad významem, pojmenuj a udělej z toho privátní metodu. Typickými kandidáty jsou cykly a případně i switche. Ovšem i třířádková inicializace nějakého buttonu či panelu si koleduje o nějakou příhodnou tovární metodu, která se dá velmi dobře recyklovat. Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".
Dost věcí se dá vyhodit z konstruktoru a umístit do deklarace atributů. Typicky inicializace interních objektů a kolekcí. Vlastně cokoli, co není závislé na parametrech konstruktoru.
-
Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil". :D
Pitomej Flanders!
Já myslím, že každej máme svýho "Flanderse".
Docela by mě zajímalo, co jiného jinak dělaáte, když (zrovna) neprogramátorujete?
-
Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil". :D
Pitomej Flanders!
Já myslím, že každej máme svýho "Flanderse".
Docela by mě zajímalo, co jiného jinak dělaáte, když (zrovna) neprogramátorujete?
Pasiem ovce a učim sa programovať v ČOBOLE
-
Docela by mě zajímalo, co jiného jinak dělaáte, když (zrovna) neprogramátorujete?
V práci jsem obyčejnej systémáček, kterej rád ví, s čím má tu čest a doma jsem obyčejnej táta. Jinak mě to vždycky táhlo trošku do hloubky problémů, jako malý javameně mě vždy po chvíli začalo víc zajímat, jak se taková hra dělá, než jak se hraje a z toho vznikla záliba v programování, nicméně jsem díky brzkým zkušenostem pochopil, že nechci být programátor na full time, protože jsem nezvládl tupě implementovat nesmysly, který si někdo vymyslí. Jinak jsem měl to veliké štěstí projít si několika málo firmami, ve kterých jsem (obzvlášť v jedné) zdědil i některá velmi kreativní díla svých předchůdců a ty bylo občas potřeba upravit/opravit. Někdy je až zábavné, jak může existovat složitý postup, který se celé roky používá, najednou se k tomu dostane někdo z IT, který musí něco udělat, napíše si na to vlastní program/skript, protože je prostě línej, někdo jej u toho nachytá, rozšíří to dál a za rok najednou nikdo neví, jak se to vlastně dělalo dřív a nikdo si to bez toho prográmku už nedokáže představit. Takto vzniká typický podnikový bastl nějakýho Franty, který tam před lety pracoval a zanechal tam touto formou svoji "stopu" :D
-
Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".
Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.
-
Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".
Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.
Taky by mě to celkem zajímalo. Dokážu si představit v IFu return a potom bez else, to co by bylo v else. Ale záleží na tom, jestli si ten return v tom IFu můžu na konkrétním místě dovolit a i když můžu, použitím else se mi ve zdrojáku dostanou krásně logicky dvě větve na stejnou úroveň ve struktuře a připadne mi to přehlednější. Na zkompilovaný výsledek by to podle mě nemělo mít žádný zásadní vliv, pokud kompilátor umí alespoň trochu optimalizovat. A nevím, jestli mi to stojí za těch pár řádků. Ale to je spíš o zvyku.
-
Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".
Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.
Taky by mě to celkem zajímalo. Dokážu si představit v IFu return a potom bez else, to co by bylo v else. Ale záleží na tom, jestli si ten return v tom IFu můžu na konkrétním místě dovolit a i když můžu, použitím else se mi ve zdrojáku dostanou krásně logicky dvě větve na stejnou úroveň ve struktuře a připadne mi to přehlednější. Na zkompilovaný výsledek by to podle mě nemělo mít žádný zásadní vliv, pokud kompilátor umí alespoň trochu optimalizovat. A nevím, jestli mi to stojí za těch pár řádků. Ale to je spíš o zvyku.
V podstatě jsi to vystihl - v ifu return nebo throw. S tím rozdílem, že obvykle ty větve přehodím. Nejprve se zbavím chybových stavů a na konci je požadovaná akce. Je to vlastně explicitní líné vyhodnocování.
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.
Na zkompilovaný výsledek by to nemělo mít zásadní vliv. Jde především o čitelnost zdrojáku.
-
V podstatě jsi to vystihl - v ifu return nebo throw. S tím rozdílem, že obvykle ty větve přehodím. Nejprve se zbavím chybových stavů a na konci je požadovaná akce. Je to vlastně explicitní líné vyhodnocování.
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.
Na zkompilovaný výsledek by to nemělo mít zásadní vliv. Jde především o čitelnost zdrojáku.
No zrovna ternární operátory podle mě moc čitelnosti kódu neprospívají, ale zkrátit kód se tím dá, to zase jo. Ale jak říkám pořád, programování je hodně o návycích, pokud člověka do něčeho netlačí místní konvence, dělá si to tak nějak jak se mu to líbí. Potom jsou z toho krásné hádky, kdo ho má většího, protože to každej dělá nejlíp :D
Mimochodem, sháním nějakou inspiraci, co si naprogramovat v Cčku, klidně nějakou konzolovou kravinku. Poslední dobou Cčko moc nepoužívám, takže občas vymyslím něco pro zábavu, naposledy to byl "řešič sudoku" :D Ideální je něco, co se dá snadno udělat a potom se dá pustit do různých optimalizací.
-
Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.
No zrovna ternární operátory podle mě moc čitelnosti kódu neprospívají, ale zkrátit kód se tím dá, to zase jo. Ale jak říkám pořád, programování je hodně o návycích, pokud člověka do něčeho netlačí místní konvence, dělá si to tak nějak jak se mu to líbí. Potom jsou z toho krásné hádky, kdo ho má většího, protože to každej dělá nejlíp :D
V Cčku je ta situace trochu jiná, ale v OO jazycích moc jiných možností není, než právě ternární operátor. Musel bys deklaraci proměnné oddělit od definice její hodnoty. Tomu se cíleně vyhýbám.
-
Povídej. Za mne je to omezení délky řádku na 120 znaků. Mně stačí 80 a ještě s rezervou. Možná to souvisí s délkou názvů identifikátorů, kde Bob doporučuje slepeninu z více slov. Je to dáno vlastnostmi germánských jazyků. Obvykle si však vystačím s jedním slovem. Samozřejmě bez zkratek.
Největší problém mám s 20ti řádky na metodu. Vim o tom, že občas i zbytečně něco rozepisuju na víc řádků, když se mi to zdá přehlednější a občas to prostě tak nějak vyplyne samo a nechce se mi dělit něco, co k sobě logicky patří a co považuji za jeden krok, na víc částí. I ty komentáře jsou občas sporný, osobně je používám tam, kde jsem musel něco moc vymýšlet a vím, že za chvíli nebudu vědět, proč jsem to tak udělal. Mám tím potom krásně označená místa, kde jsem to dělal moc složitě a je to dobrý začátek při případném refaktoringu :D Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil". :D
Tak s tímto pravidlem bych si hlavu nelámal, zejména pokud účelně výrazy rozděluješ na více řádek. Také to tak dělám. Když metoda vyjde na 30 řádek, tak je to stále OK, to číslo je prostě "měkké". Pokud se ti nějaká metoda jeví dlouhá, vyber si z ní nějaký scope, zamysli se nad významem, pojmenuj a udělej z toho privátní metodu. Typickými kandidáty jsou cykly a případně i switche. Ovšem i třířádková inicializace nějakého buttonu či panelu si koleduje o nějakou příhodnou tovární metodu, která se dá velmi dobře recyklovat. Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".
Dost věcí se dá vyhodit z konstruktoru a umístit do deklarace atributů. Typicky inicializace interních objektů a kolekcí. Vlastně cokoli, co není závislé na parametrech konstruktoru.
Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.
-
Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.
Můžu se jen zeptat, co to bylo za systém? Podle úrovně optimalizace bych očekával něco malýho, na druhou stranu, pokud je odmocnina jedna instrukce, tak to musí mít FPU, tak mě zajímá, jestli je něco bastlířského, co se dá použít i na rychlejší výpočty, nebo to byl nějakej relativně velkej CPU a šlo jen o rychlost toho realtimu?
-
Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.
Dělám hlavně v objektových jazycích, ve kterých jsou trochu jiné zvyklosti a mé postupy vedou sekundárně k jistému zefektivnění a zrychlení výpočtu v rámci OOP. Navíc objektové jazyky běžně optimalizují privátní metody tak, že je expandují jako makro - obejde se to bez zmíněného náročného volání. Je to hezky vidět u privátních getterů/setterů, které se v benchmarku chovají, jako kdybys pracoval přímo s daným atributem.
Ve tvém případě bych se asi snažil odmocňování nahradit násobením, které je podstatně rychlejší. Jistě, nejde to vždy, ale například pro hledání minimální či maximální vzdálenosti je to perfektní.
-
-O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace
O3 nedělá nic nebezpečného ani nestandardního, kontroly na NULL vyhazuje až _PO_ dereferenci pointeru. Pokud program nefungoval s O3, tak byl vadný a že fungoval s jiným levelem optimalizací, byla jen náhoda. Takový program je potřeba opravit a ne vypínat O3.
-
Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.
Můžu se jen zeptat, co to bylo za systém? Podle úrovně optimalizace bych očekával něco malýho, na druhou stranu, pokud je odmocnina jedna instrukce, tak to musí mít FPU, tak mě zajímá, jestli je něco bastlířského, co se dá použít i na rychlejší výpočty, nebo to byl nějakej relativně velkej CPU a šlo jen o rychlost toho realtimu?
Slo pouze o rychlost toho realtimu.
@Kit: Jednalo se o prepocet souradnic z WGS84 na polarni souradnice vuci bodu na mape.
@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.
-
@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.
Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.
Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...
-
@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.
Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.
Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...
Na tohle se dobře hodí návrhový vzor NullObject. Kontroly se pak dají v klidu vyhodit.
-
Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.
Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...
Kde jsi prisel na to, ze to pri O3 pada? Cim vetsi level optimalizace, tim vetsi riziko bugu prekladace. Radeji pouziju O2 a nejake bottlenecky vyresim rucne, viz. odmocnina, nez riskovat, ze si prekladac zablbne a shodi to.
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.
-
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.
Pobavilo :D Vzpoměl jsem si na tchána, ten vždy říká "Jsem skromný člověk, spokojím se jen s tím nejlepším a nic jiného nechci a nepotřebuji" :D
-
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.
Pobavilo :D Vzpoměl jsem si na tchána, ten vždy říká "Jsem skromný člověk, spokojím se jen s tím nejlepším a nic jiného nechci a nepotřebuji" :D
Existují aplikace, pro které je i šest devítek málo. Zejména pokud jde o životy.
-
Kde jsi prisel na to, ze to pri O3 pada? Cim vetsi level optimalizace, tim vetsi riziko bugu prekladace. Radeji pouziju O2 a nejake bottlenecky vyresim rucne, viz. odmocnina, nez riskovat, ze si prekladac zablbne a shodi to.
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.
Aha, takže místo abys zapnul O3, tak radši budeš ručně bastlit vlastní kód, ve kterém je mnohem větší riziko chyby, než při zapnutí O3 optimalizace? No je to tvoje volba...
-
Existují aplikace, pro které je i šest devítek málo. Zejména pokud jde o životy.
Ale to ano, šest devítek beru, klidně deset, ale čistá 100? :D
-
Existují aplikace, pro které je i šest devítek málo. Zejména pokud jde o životy.
Ale to ano, šest devítek beru, klidně deset, ale čistá 100? :D
Obvykle je lepší si něco pomyslet o naivitě a neřešit to.
Pokud je nutná maximální spolehlivost, je nutné k tomu udělat patřičné množství testů včetně vkládání nesmyslných hodnot či null pointerů. Pak už je jedno, zda je O3 zapnuté či nikoli.
-
Kde jsi prisel na to, ze to pri O3 pada? Cim vetsi level optimalizace, tim vetsi riziko bugu prekladace. Radeji pouziju O2 a nejake bottlenecky vyresim rucne, viz. odmocnina, nez riskovat, ze si prekladac zablbne a shodi to.
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.
Kolko bugov prekladaca si nasiel v takom GCC a kolko bugov si spravil ty? Ja som za poslednych pat rokov nasiel jeden bug v GCC a sam som spravil bugov mozno tisice.
Pri O3 sa zapinaju optimalizacie, ktore nafukuju binarku, cim mozu vykonavanie aj trochu spomalit. Prekladac celkovo neblbne, akurat sa chova podla specifikacie.
To sa hned poznaju antipatterny:
- chybajuci volatile (nepise sa do pamati, reorderuje sa)
- spoliehanie sa na funkciu, v ktorej sa nachadzam bez noinline - proste inlineuje sa skoro vsetko
- vynechava sa nepotrebny kod: ked sa vysledok nepouzije a funkcia dokazatelne nema side effect, tak sa funkcia ani nezavola
- ak k niecomu uzivatel podla specifikacie nema mat pristup a pouzije hack ako pole[-10], tak to kompilator podla predchadzajuceho bodu neodhali
- ked uzivatel kompilatoru neprezradi, co robi v svojom assembleri, tak to kompilator s kodom preusporiada tak, ako uzna za vhodne, aby bol vykon co najlepsi
-
Related: https://www.reddit.com/r/learnprogramming/comments/4y7e3d/i_began_teaching_myself_to_code_a_year_ago_i_got/
-
Pokracuj s C na linuxu. Napr. pomoci libcurl, rapidjson, rapidxml si zkus stahnout neco z webu a nejak to rozparsovat a treba ulozit do souboru. Jo a nejlepe to udelej na RPi.
-
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Takže jestli to chápu dobře, tak tím, že vyhodím else a nahradím ho extra metodou docílím toho, že metoda bude dělat jen jednu věc a pořádně? To jako vážně?
Tvé zkratky jsou fantastické. Jsem docela rád, že už nejsem začátečník a nemusím se od tebe učit.
-
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Takže jestli to chápu dobře, tak tím, že vyhodím else a nahradím ho extra metodou docílím toho, že metoda bude dělat jen jednu věc a pořádně? To jako vážně?
Tvé zkratky jsou fantastické. Jsem docela rád, že už nejsem začátečník a nemusím se od tebe učit.
Na negativních příkladech se dá taky lecčemus naučit ;)
-
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Takže jestli to chápu dobře, tak tím, že vyhodím else a nahradím ho extra metodou docílím toho, že metoda bude dělat jen jednu věc a pořádně? To jako vážně?
Tvé zkratky jsou fantastické. Jsem docela rád, že už nejsem začátečník a nemusím se od tebe učit.
Učit začátečníky je jednodušší, než učit blbce :)
Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.
-
Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.
(1 + 2) is equals (2 + 1)
-
Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.
(1 + 2) is equals (2 + 1)
Tohle sice v Euklidovském prostoru platí, ale co to má společného s "else"?
-
V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.
Takže jestli to chápu dobře, tak tím, že vyhodím else a nahradím ho extra metodou docílím toho, že metoda bude dělat jen jednu věc a pořádně? To jako vážně?
Tvé zkratky jsou fantastické. Jsem docela rád, že už nejsem začátečník a nemusím se od tebe učit.
Jedna vec a poradne neni urcite vyhozeni else. U ifu muze byt ta jedna vec rozhodnuti (t.j. metoda pak obsahuje if/else, kde je v kazde vetvi jeom volani dalsich funkci).
Na druhou stranu - zrovna tohle nekdy pomuze a nekdy ne. Pokud jsou obe vetve kratke, tak se muze vyplatit nebazirovat na doslovne jedne veci a nerefaktorovat kod "na krev".
-
Jedna vec a poradne neni urcite vyhozeni else. U ifu muze byt ta jedna vec rozhodnuti (t.j. metoda pak obsahuje if/else, kde je v kazde vetvi jeom volani dalsich funkci).
Na druhou stranu - zrovna tohle nekdy pomuze a nekdy ne. Pokud jsou obe vetve kratke, tak se muze vyplatit nebazirovat na doslovne jedne veci a nerefaktorovat kod "na krev".
Jde spíš o zrušení větve "else" bez náhrady. Program se tím zkrátí, počet podmínek zůstává a funkčnost je zachována. Větve "else" totiž bývají zbytečné a pouze zhoršují čitelnost programu.
To se samozřejmě netýká ternárního operátoru (tedy výrazu), ale pouze větvení příkazů.
-
;D
-
Jde spíš o zrušení větve "else" bez náhrady.
Pokud má program dělat to, co předtím, tak je náhrada nutná. Tipoval bych, že tou náhradou jsou returny. Mám pravdu?
Jestli jo, tak to raději to else.
-
Jde spíš o zrušení větve "else" bez náhrady.
Pokud má program dělat to, co předtím, tak je náhrada nutná. Tipoval bych, že tou náhradou jsou returny. Mám pravdu?
Jestli jo, tak to raději to else.
return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
-
Jde spíš o zrušení větve "else" bez náhrady.
Pokud má program dělat to, co předtím, tak je náhrada nutná. Tipoval bych, že tou náhradou jsou returny. Mám pravdu?
Jestli jo, tak to raději to else.
return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.
A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.
-
Jde spíš o zrušení větve "else" bez náhrady.
Pokud má program dělat to, co předtím, tak je náhrada nutná. Tipoval bych, že tou náhradou jsou returny. Mám pravdu?
Jestli jo, tak to raději to else.
return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.
A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.
Souhlas, return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.
-
return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.
To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.
Zápis bez else vypadá tak, že na začátku metody pomocí podmínek ošetřím vstupy a pak teprve provedu požadovanou akci. Nevidím žádný důvod k tomu, aby ta požadovaná akce byla odsazena a zanořena kamsi do víceúrovňového "else".
-
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
-
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Tak se podívej do vygenerovaného asembleru, jak to "není" goto. Pokud teda znáš asembler...
-
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Ved return ma adresu, aby vedel, kam skocit s vysledkom, resp pre navrat.
-
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Tak se podívej do vygenerovaného asembleru, jak to "není" goto. Pokud teda znáš asembler...
Když se podívám do returnu vygenerovaného do assembleru, tak tam goto skutečně není.
-
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Tak se podívej do vygenerovaného asembleru, jak to "není" goto. Pokud teda znáš asembler...
Když se podívám do returnu vygenerovaného do assembleru, tak tam goto skutečně není.
Tak se podívej znova. Případně někoho požádej, ať ti ten strojový kód vysvětlí.
-
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Ved return ma adresu, aby vedel, kam skocit s vysledkom, resp pre navrat.
Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.
-
Když se podívám do returnu vygenerovaného do assembleru, tak tam goto skutečně není.
Tak se podívej znova. Případně někoho požádej, ať ti ten strojový kód vysvětlí.
Tak se podívej na adresu toho tvého returnového goto. Kam skáče?
-
GOTO se používalo pro návrat hodnoty?
-
GOTO se používalo pro návrat hodnoty?
Ne, k tomuto účelu se goto ani použít nedá.
-
Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Ved return ma adresu, aby vedel, kam skocit s vysledkom, resp pre navrat.
Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.
To neznáš Fortran 77 :o
-
Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.
To neznáš Fortran 77 :o
Různé jazyky mohou mít rozdílné implementace. Instrukce pro return v assembleru (ke kterému jsme mezitím zavítali) žádnou návratovou adresu nemá, protože ji ani mít nemůže. Viz výše.
-
Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.
(1 + 2) is equals (2 + 1)
Tohle sice v Euklidovském prostoru platí, ale co to má společného s "else"?
To byla jen taková decentní narážka na to, že když poukážeš na blbost, kterou jsem neřekl, tak nezachráníš skutečnost, že si řekl blbost.
-
return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
To hodně záleží na jazyku. Návratové kódy z minulého století často dokazují, že páni inženýři dříve to měli více vykoumané, než páni programátoři dneska.
Výjimky jsou nutnou cestou u jazyka, kde nelze zajistit odebrání si výsledku. V ostatních případech je to spíše komplikace.
A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.
To je dnes už zastaralá teorie jednoho návratového bodu.
Ale!? A to řekl kdo? A já měl naopak pocit, že tato zastaralá teorie zažívá comeback, páč jsme si ty slepé uličky prošli. To sou věci...
Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.
Já si přeci kůli tomu, abych se zbavil nějakých konstrukcí které se nějakému Kitovi nelíbí nebudu zasí**t kontrakt.
na začátku metody pomocí podmínek ošetřím vstupy a pak teprve provedu požadovanou akci.
Nejvíce úsměvné je to, že já to takhle dělám taky. Ale z úplně jiných důvodů. Tvá argumentace, že nechceš používat else je prostě střelená. Hledáš magii, kde žádná není.
-
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
Vynimky su "radost", teda aspon tie non-checked. Ked padaju cez viac levelov, tak funguju ako spolahliva obfuskacia, lebo nie su jasne vidiet urovne abstrakcie. Ide to uplne proti zvladnutelnemu programovaniu, kde zavolam funkciu a ta mi vrati hodnotu bez toho, aby som sa staral, ako k nej dosla. Naopak, treba poznat implementaciu do najmensieho detailu.
Ked neviem, co za nedokumentovanu vynimku vyleti, tak dokazem najviac nejaky univerzalny catch all, ktory aj tak nebude spravne* fungovat, lebo neviem, o aku chybu sa jedna. Z necheckovanych vynimiek spolahlivo a spravne funguje iba vynimka = koniec aplikacie, co je u kniznice neprijemne.
*spravnym fungovanim nemyslim hlasenie uzivatelovi ako od user-friendly vyrobcu: "Fatal error. Abort, Retry, Fail?".
-
Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.
To neznáš Fortran 77 :o
Různé jazyky mohou mít rozdílné implementace. Instrukce pro return v assembleru (ke kterému jsme mezitím zavítali) žádnou návratovou adresu nemá, protože ji ani mít nemůže. Viz výše.
Přímo návratovou adresu ne, ale může si vybrat z několika předem připravených, i 8086 to umí. A podívej se na konci té stránky na "Alternate RETURN Statement", to se ti bude líbit: http://www.obliquity.com/computer/fortran/procedure.html ;D
-
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
Vynimky su "radost", teda aspon tie non-checked. Ked padaju cez viac levelov, tak funguju ako spolahliva obfuskacia, lebo nie su jasne vidiet urovne abstrakcie. Ide to uplne proti zvladnutelnemu programovaniu, kde zavolam funkciu a ta mi vrati hodnotu bez toho, aby som sa staral, ako k nej dosla. Naopak, treba poznat implementaciu do najmensieho detailu.
Ked neviem, co za nedokumentovanu vynimku vyleti, tak dokazem najviac nejaky univerzalny catch all, ktory aj tak nebude spravne* fungovat, lebo neviem, o aku chybu sa jedna. Z necheckovanych vynimiek spolahlivo a spravne funguje iba vynimka = koniec aplikacie, co je u kniznice neprijemne.
*spravnym fungovanim nemyslim hlasenie uzivatelovi ako od user-friendly vyrobcu: "Fatal error. Abort, Retry, Fail?".
Výjimky mi fungují zcela bez problémů, žádné obfuskace v nich nevidím. Při propadu přes více úrovní musí být samozřejmě součástí rozhraní a v případě potřeby je nutné je konvertovat.
Nevidím důvod, proč bych se měl starat o to, jakou hodnotu mi funkce vrací. Je to součástí její kompetence, která je řádně podchycena v testech. Při běhu ji tedy kontrolovat nemusím.
-
Výjimky mi fungují zcela bez problémů, žádné obfuskace v nich nevidím. Při propadu přes více úrovní musí být samozřejmě součástí rozhraní a v případě potřeby je nutné je konvertovat.
Ok, takze ked chytame vynimku na kazdej urovni abstrakcie, tak o co je to lepsie od vracania rovno chyby + navratovej hodnoty? Tym myslim pristup ako v Go, kde sa normalne vracia dvojica (hodnota, error).
Ked nechytame vynimky na kazdej urovni, tak nastava ten chaos, ze zavolam stiahnutie stranky a vyleti na mna UnknownCharacterException a musim ist az do najnizsej urovne, aby som zistil, ze niekto pridal overovanie platnosti Unicode znakov.
Nevidím důvod, proč bych se měl starat o to, jakou hodnotu mi funkce vrací. Je to součástí její kompetence, která je řádně podchycena v testech. Při běhu ji tedy kontrolovat nemusím.
Podchytenie v testoch funguje len bez cudzieho kodu a len bez chyb a zabudania. Urcite mate testy cudzej kniznice, ktore overuju aj vsetky vynimky, ktore vracia? Kde je istota, ze tam nikto neprida dalsiu "internu" vynimku, ktora vybuble von?
Ked sa bude funkcia bez exception pri nejakych vstupoch mylit, tak sa to da stale izolovat a dobre debugovat. Ked bude vyhadzovat exception a niekto tu exception raz nechyti, tak to bude bublat az niekam vysoko, tam to niekto nahodou chyti a z divnych dovodov sa nebude vykonavat cast kodu. A ten co to chytil nema sancu poznat, ze tu vynimku hodil niekto hlbsie v hierarchii ako sa cakalo a jeho reakcia bude v principe nezmyselna.
-
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.
Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat. Někdy je daleko lepší neházet (klasika je NumberFormatException z Javy)
Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit.
To teda neobsahuje právě proto, že propadává nahoru. Neobsahuje nic, co do ní sám nenacpu.
Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně.
Já psal o "očekávaných" chybách. Ale zapomenutá výjimka je taky bug. Když zapomenu ošetřit nějakou výjimku, tak probublá ven, kde se už může leda tak hádat, co se vlastně stalo. Program může tak akorát padnout na hubu a případně poslat stacktrace mailem.
Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.
To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.
He? Vždyť return dělá to co break. Jen pro jiné složené závorky.
-
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.
Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat.
Proc by "rozumne API" melo umoznit u takove zakladni veci vyber? Tvurce toho API by mel zvolit jedu dobrou variantu (v pripade C??/Java/Python-like jazyku vyjimku) a te se drzet.
-
Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.
Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat. Někdy je daleko lepší neházet (klasika je NumberFormatException z Javy)
Výjimky mi vyhovují víc. Mám s nimi méně práce a dobře se testují.
Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit.
To teda neobsahuje právě proto, že propadává nahoru. Neobsahuje nic, co do ní sám nenacpu.
Zas tak moc ji propadávat nenechám. Pokud si nevytváříš vlastní třídy výjimek, tak zřejmě budou mít nízkou vypovídací schopnost.
Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně.
Já psal o "očekávaných" chybách. Ale zapomenutá výjimka je taky bug. Když zapomenu ošetřit nějakou výjimku, tak probublá ven, kde se už může leda tak hádat, co se vlastně stalo. Program může tak akorát padnout na hubu a případně poslat stacktrace mailem.
Co je to "zapomenutá výjimka"? To neznám.
Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.
Haskel je zajímavý jazyk, který výjimky řeší zcela jinak než objektové jazyky. O výjimkách v C++ platí totéž - tam je to spíš parodie na výjimky. Nedivím se, že ti nevyhovují.
To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.
He? Vždyť return dělá to co break. Jen pro jiné složené závorky.
Return na rozdíl od break vrací nějakou hodnotu. V C++ se tak dají vracet jen hodnoty primitivních typů, takže to neoceníš. V objektových jazycích mi return ve switchi obvykle vrací hotové objekty - break by mi v takovém případě nebyl nic platný.
-
Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.
Vyjímky se dají potlačit různými způsoby. V Pythonu by to šlo třeba wrapperem a vracet tuple:
import functools
def silenced(func, defaultval=None):
@functools.wraps(func)
def f(*args, **kwargs):
try:
return (func(*args, **kwargs), None)
except Exception as e:
return (defaultval, e)
return f
def test1(err):
"""
>>> silenced(test1)(False)
('OK', None)
>>> silenced(test1, 1)(True)
(1, Exception('Not OK',))
>>> test1 = silenced(test1)
>>> (res, _) = test1(False)
>>> res
'OK'
"""
if err:
raise Exception('Not OK')
else:
return 'OK'
@functools.partial(silenced, defaultval=False)
def test2():
"""
>>> test2()
(False, Exception('Not OK',))
"""
return test1(True)
Je to jen takový nástřel. Neručím za to. Nevidím důvod proč to tak dělat. Namísto zachytávání výjimky je třeba testovat návratovou hodnotu.
-
Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.
Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.
Haskel je zajímavý jazyk, který výjimky řeší zcela jinak než objektové jazyky. O výjimkách v C++ platí totéž - tam je to spíš parodie na výjimky. Nedivím se, že ti nevyhovují.
Přečti si pořádně, na co jsem reagoval. Já psal, že na přibalení chybového kódu k vracené hodnotě není nic složitého ani nepříjemného. O tom, že by mi výjimky nevyhovovaly, jsem nepsal. Naopak je používám, když se hodí víc než chybové kódy.
To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.
He? Vždyť return dělá to co break. Jen pro jiné složené závorky.
Return na rozdíl od break vrací nějakou hodnotu.
I return bez parametru? A return s parametrem si můžeš porovnat s přířazením+break. Furt je to tak rozdílné?
V C++ se tak dají vracet jen hodnoty primitivních typů, takže to neoceníš.
Blbost. Dá se vracet cokoliv kopírovatelného.
-
Proc by "rozumne API" melo umoznit u takove zakladni veci vyber? Tvurce toho API by mel zvolit jedu dobrou variantu (v pripade C??/Java/Python-like jazyku vyjimku) a te se drzet.
... Nevidím důvod proč to tak dělat. Namísto zachytávání výjimky je třeba testovat návratovou hodnotu.
Důvod je ten, že testování návratových hodnot občas vede k daleko přehlednějšímu kódu. Rozhodně netvrdím, že vždycky. Hodí se to, pokud ošetřuju chybu hodně blízko místa vzniku a vím že se to bude stávat celkem často. Jako dobrý příklad mi přijde třeba parsování vstupu od uživatele. V Javě třeba spoustě lidí chybí něco jako TryParseInt.
-
Return na rozdíl od break vrací nějakou hodnotu.
I return bez parametru? A return s parametrem si můžeš porovnat s přířazením+break. Furt je to tak rozdílné?
[/quote]
Return bez parametru jsem už hodně dlouho nepoužil. U funkcí mi return vrací výsledek, u procedur stavový kód provedené operace nebo počet provedených změn. Break mi prostě nevyhovuje.
-
Důvod je ten, že testování návratových hodnot občas vede k daleko přehlednějšímu kódu. Rozhodně netvrdím, že vždycky. Hodí se to, pokud ošetřuju chybu hodně blízko místa vzniku a vím že se to bude stávat celkem často. Jako dobrý příklad mi přijde třeba parsování vstupu od uživatele. V Javě třeba spoustě lidí chybí něco jako TryParseInt.
Pokud myslíš TryParseInt z c#, tak to bych stejně asi většinou použil takto:
int intValue = int.TryParse(stringValue, out intValue) ? intValue : 0;
Není to o moc bezpečnější než funkce vyhazující výjimku.
-
Pokud myslíš TryParseInt z c#, tak to bych stejně asi většinou použil takto:
int intValue = int.TryParse(stringValue, out intValue) ? intValue : 0;
Není to o moc bezpečnější než funkce vyhazující výjimku.
Nula pro libovolný nečíselný brajgl je málokdy to, co by člověk chtěl.
-
Return bez parametru jsem už hodně dlouho nepoužil. U funkcí mi return vrací výsledek, u procedur stavový kód provedené operace nebo počet provedených změn. Break mi prostě nevyhovuje.
Neargumentuješ náhodou celou dobu, že je lepší místo chybových kódů používat výjimky? Stavový kód je jeden konkrétní příkad chybového kódu. ;)
-
Return bez parametru jsem už hodně dlouho nepoužil. U funkcí mi return vrací výsledek, u procedur stavový kód provedené operace nebo počet provedených změn. Break mi prostě nevyhovuje.
Neargumentuješ náhodou celou dobu, že je lepší místo chybových kódů používat výjimky? Stavový kód je jeden konkrétní příkad chybového kódu. ;)
Spíše naopak, chybový kód je příkladem stavového kódu. Stav HTTP 200 rozhodně není chybou, ale stavem, že je vše OK. Stavový kód může volající ignorovat, ale výjimku musí zpracovat nebo předat dále. Výjimku by neměl polykat, může ji konvertovat do stavového kódu (např. HTTP 404).
Vše závisí na definovaném rozhraní. Buď přímo uvnitř aplikace, anebo mezi aplikacemi.
-
Spíše naopak, chybový kód je příkladem stavového kódu. Stav HTTP 200 rozhodně není chybou, ale stavem, že je vše OK. Stavový kód může volající ignorovat, ale výjimku musí zpracovat nebo předat dále. Výjimku by neměl polykat, může ji konvertovat do stavového kódu (např. HTTP 404).
Vše závisí na definovaném rozhraní. Buď přímo uvnitř aplikace, anebo mezi aplikacemi.
Tohle ale přece tvrdím celou dobu. Občas je lepší použít výjimky a občas zase stavové kódy.
-
Neměl jsem čas číst celé vlákno, tak snad nebudu někoho opakovat.
Sice přihlédnout k poptávce trhu je sice důležité. Ale myslím, že by se nikdo neměl tímto řídit majoritně. Každá práce by se měla dělat srdcem. A u této krásné profese to platí dvojnásob, protože vyžaduje neustálý rozvoj a sledování nejnovějších trendů.
Dejte si pozor, nikdo Vám objektivně neporadí jazyk. To že jeden říká, že mu přijde python lepší než java je jeho subjektivní názor a i kdyby to byla stokrát pravda. Tak pokud Vám se prostě nebude líbit, pak nemá smysl se ohýbat. Naštěstí existuje X jazyků.
Např: Někdo začíná u silně typových jazyků a cítí se omezován, tak přejde na slabě typové. Já naopak čím déle programuji, tím více tíhnu k jasným pravidlům.
Node.js je zajímavá technologie, ale co naplat, když Javasctript není můj šálek kávy a používání preprocessorů mi přijde jen jako když uklidíte tak, že nepořádek naházíte do místnosti kam se moc nechodí. Všude to máte pěkné, ale o tom nepořádku prostě víte.
Můžu snad podávat špičkové výkony, když nevěřím technologii ve které dělám?
Rozhodně se Vám ten jazyk musí líbit. Musí Vás bavit. Jasně, změnit ho můžete vždy, a většina znalostí je přenositelná, ale spousta také ne.
Další důležitá vlastnost je vyzrálost jazyka, komunita a množství a kvalita knihoven. Java už je lety prověrená, doplňují se tam víceméně jen nějaké ty lahůdky. Oproti tomu PHP po dvaceti letech dostává funkcionality, které jiná jazyky umí už od začátku.
Nespokojte se s tím, že Vám 100 lidí řekne: Java. To vám sdělí možná jen to, že jste se zeptal stovky javistů. Asi bych si vypsal jazyky, které připadají v úvahu a sepsal bych si subjektivní i objektivní plusy a mínusy...
-
Keby sa kazdy komentar odvijal v podobnom duchu ako napisal Hapi, tak by uroven na roote vyrazne stupla. :)
-
Neměl jsem čas číst celé vlákno, tak snad nebudu někoho opakovat.
Sice přihlédnout k poptávce trhu je sice důležité. Ale myslím, že by se nikdo neměl tímto řídit majoritně. Každá práce by se měla dělat srdcem. A u této krásné profese to platí dvojnásob, protože vyžaduje neustálý rozvoj a sledování nejnovějších trendů.
Dejte si pozor, nikdo Vám objektivně neporadí jazyk. To že jeden říká, že mu přijde python lepší než java je jeho subjektivní názor a i kdyby to byla stokrát pravda. Tak pokud Vám se prostě nebude líbit, pak nemá smysl se ohýbat. Naštěstí existuje X jazyků.
Např: Někdo začíná u silně typových jazyků a cítí se omezován, tak přejde na slabě typové. Já naopak čím déle programuji, tím více tíhnu k jasným pravidlům.
Node.js je zajímavá technologie, ale co naplat, když Javasctript není můj šálek kávy a používání preprocessorů mi přijde jen jako když uklidíte tak, že nepořádek naházíte do místnosti kam se moc nechodí. Všude to máte pěkné, ale o tom nepořádku prostě víte.
Můžu snad podávat špičkové výkony, když nevěřím technologii ve které dělám?
Rozhodně se Vám ten jazyk musí líbit. Musí Vás bavit. Jasně, změnit ho můžete vždy, a většina znalostí je přenositelná, ale spousta také ne.
Další důležitá vlastnost je vyzrálost jazyka, komunita a množství a kvalita knihoven. Java už je lety prověrená, doplňují se tam víceméně jen nějaké ty lahůdky. Oproti tomu PHP po dvaceti letech dostává funkcionality, které jiná jazyky umí už od začátku.
Nespokojte se s tím, že Vám 100 lidí řekne: Java. To vám sdělí možná jen to, že jste se zeptal stovky javistů. Asi bych si vypsal jazyky, které připadají v úvahu a sepsal bych si subjektivní i objektivní plusy a mínusy...
Vtip je v tom, že PHP/FI už mělo pro svět webu takové praktické funkcionality, ke kterým se ostatní jazyky propracovaly až za 10 let, proto se PHP taky rozšířilo.
Trh rozhodně s větší pravděpodobností lépe, než individuální názor odborníka.
-
Hledáš magii, kde žádná není.
Vytisknout a nalepit na monitor. Povinně.
Zatímco si honíte péra při odstraňování else z kódů, tak jiní stihli dokončit další projekt.
-
Např: Někdo začíná u silně typových jazyků a cítí se omezován, tak přejde na slabě typové. Já naopak čím déle programuji, tím více tíhnu k jasným pravidlům.
Další důležitá vlastnost je vyzrálost jazyka, komunita a množství a kvalita knihoven. Java už je lety prověrená, doplňují se tam víceméně jen nějaké ty lahůdky. Oproti tomu PHP po dvaceti letech dostává funkcionality, které jiná jazyky umí už od začátku.
Vtip je v tom, že PHP/FI už mělo pro svět webu takové praktické funkcionality, ke kterým se ostatní jazyky propracovaly až za 10 let, proto se PHP taky rozšířilo.
PHP má dnes dynamické i statické typování, je možné si vybrat. Podobně je možné si vybrat, zda objekty budou třídní či prototypové. Mohu si vybrat, zda budu programovat špagetově, strukturovaně, funkcionálně či objektově. Vše mohu libovolně kombinovat dle potřeby. Pro někoho to znamená totální chaos, jiný si stanoví pevná pravidla a je v pohodě.
Ano PHP dnes dostává některé funkcionality, které jiné jazyky umí od začátku. Platí to však i naopak. PHP má mnoho vlastností, o kterých si ostatní jazyky nechávají jen zdát.
-
PHP má mnoho vlastností, o kterých si ostatní jazyky nechávají jen zdát.
Pokud je těch vlastností dosaženo tím, že "se všechno může"*, tak to není přednost. Nejvíc takových vlastností/možností má assembler... Procedurálněfunkcionálněobjektový kočkopes není žádá výhra, ale právě naopak. V programování je nejhorší, když si člověk "může vybrat".
* "všechno se může" znamená "o ničem nemám žádnou jistotu". Opravdu zajímavé vlastnosti jazyk získává tím, že něco zakáže, ne tím, že něco povolí. Něco zakázat znamená dávat garance.
-
PHP má mnoho vlastností, o kterých si ostatní jazyky nechávají jen zdát.
Pokud je těch vlastností dosaženo tím, že "se všechno může"*, tak to není přednost. Nejvíc takových vlastností/možností má assembler... Procedurálněfunkcionálněobjektový kočkopes není žádá výhra, ale právě naopak. V programování je nejhorší, když si člověk "může vybrat".
* "všechno se může" znamená "o ničem nemám žádnou jistotu". Opravdu zajímavé vlastnosti jazyk získává tím, že něco zakáže, ne tím, že něco povolí. Něco zakázat znamená dávat garance.
Socialismus nefugnuje. Zářným příkladem je Javascript a jeho paskřivení obezličkami implementované neprototypové OOP. Člověk má být svobodný, má mít možnost hřešit, a kvalitu pak představuje dobrovolné nehřešení. Kaviltní má být autor a ne jazyk.
-
PHP má mnoho vlastností, o kterých si ostatní jazyky nechávají jen zdát.
Pokud je těch vlastností dosaženo tím, že "se všechno může"*, tak to není přednost. Nejvíc takových vlastností/možností má assembler... Procedurálněfunkcionálněobjektový kočkopes není žádá výhra, ale právě naopak. V programování je nejhorší, když si člověk "může vybrat".
* "všechno se může" znamená "o ničem nemám žádnou jistotu". Opravdu zajímavé vlastnosti jazyk získává tím, že něco zakáže, ne tím, že něco povolí. Něco zakázat znamená dávat garance.
Jazyky s jedním paradigmatem jsou prakticky nepoužitelné nebo přinejmenším neoblíbené. V případě multiparadigmatického jazyka záleží na sebekázni programátora, aby vestavěné funkce či syntaktický cukr používal správným způsobem. C# má syntaktický cukr pro gettery a settery a jaký paskvil z toho vznikl. Kdekdo toho zneužívá.
-
V případě multiparadigmatického jazyka záleží na sebekázni programátora
Ještě jednou: omezení dává znalost, ze znalosti plynou garance. Pokud nevím, jestli programátor udržel sebekázeň, nemám žádnou znalost a tímpádem ani garanci ani optimalizaci.
-
Jazyky s jedním paradigmatem jsou [...] přinejmenším neoblíbené.
Nejoblíbenější deník v Česku je Blesk.
-
No... Tak předně ten komentář jsem nepsal za účelem vyvolání bouřlivé diskuze na téma: Jak to vypadá s PHP.
Já osobně v PHP programuji od svých 14ti let a tedy 16 let, z toho 10 let profesionálně. Takže moje narážka na PHP nebyla mířena jako útok.
Za ty roky jsem více či méně poznal i jiné jazyky, ať už během kariéry a nebo hraním si po večerech. Majoritně Java a Python.
Je mi jasné, že to co teď napíšu nepovede ke zdárnému uzavření této debaty, která je spíše k pivu, než na fórum. Bohužel jsem nedokázal být natolik vyrovnaný, abych nepřijal hozenou rukavici.
PHP už dnes má vcelku dobrý základ. Kdo někdy viděl zdrojové kódy interpretu a to hlavně před vydáním sedmé verze, pak chápe, že PHP je venku huj, uvnitř fuj. Je to moloch, který vznikl za úplně jiným účelem, než ke kterému se používá dnes. A tím započala jeho cesta navrchol.
PHP vzniklo podobně jako MySQL. Původně vytvořeno tak aby bylo primitivní a později pod tlakem komunity vyrostlo na stejnou složitost, kterou mají jiné jazyky. Mělo se jednat o dynamický šablonovací systém, ve kterém se dají dělat obyčejné weby alespoň trochu efektivně.
V PHP stačilo a stačí relativně málo, aby v něm kdokoliv "cokoliv" udělal. Stačí Vám podmínky, include a cykly a máte statický web bez duplicit. A i proto se zažilo dogma, že PHP programátoři jsou bastlíři a lepiči kódu. Pro hnidopichy: To je asi 10 let dozadu.
Dlouho chyběly nástroje na na správu knihoven. Nejednotnost nastavení webhostingů vedla k tomu, že projekty byly nepřenositelné. Všichni jsme se báli extensions a psali si vlastní knihovny. Zde nastal boom až v nedávné době - composer, docker atd. A i samotný deploy je pro svět PHP docela nová věc a divili byste se, jak velké projekty dodnes používají FTP a ruční deploy.
Nicméně dodnes má PHP nejednotné jmenné konvence, každá funkce má jiné pořadí parametrů. Nelogické chování. Nikdy nenaimplementujete ArrayAccess tak, aby se choval naprosto identicky jako pole. Konkrétně se jedná o $a[null] = 'foo'; a $a[''] = 'foo';
Magické přetypování a díky tomu nelogické fungování jazykových konstruktů. Tyto podivnosti (a je jich mnohonásobně více) nejsou až tak známé a vedou k hnusným a špatně se odhalujícím chybám.
Ad statické typování. On to je zas jen po PHPčkovsku vyřešený problém. PHP 7 je už na světě nějaký pátek, ale opět nepoužitelné a verze 7.1 to malinko vylepší. Zatím ve stabilní verzi nelze použít null, pokud použijete type hint. Možnost vracet void, není až tak blocker, ale je to důkaz toho, že někdo nepřemýšlel.
Type hinting zatím není možný pro properties, proměnné a konstanty. My na projektu máme u poloviny metod komentář @todo hint a čekáme na novou verzi a to my si zaplať pánbůh můžeme dovolit aktualizovat prostředí jak se nám zlíbí. Ale většina chudáků na nové verze čeká do doby, kdy jsou staré a nemají prostor refaktorovat natolik, aby sílo novějších verzí využili.
A proto trvám na svém. NE, statické typování není možné, protože je tak 30%. Takže si na to můžeme jen a jen hrát. Nemůžeme ani říct, že metoda přijímá pouze pole objektů daného typu. Pole není Traversable.
Ano, četl jsem RFC, naposledy včera. Svítá na lepší časy, ale hodně si počkáme.
Mám ale obavu, že to je zas vše jen navenek. Podle mě by měli udělat to, co python. Udělat novou verzi a od základu jí udělat znovu, vyházet veškeré nesmysly a nechat tam to, co má smysl.
HHVM a hacklang je to, co bych čekal od PHP.
-
Jazyky s jedním paradigmatem jsou [...] přinejmenším neoblíbené.
Nejoblíbenější deník v Česku je Blesk.
Nejoblíbenějšími programovacími jazyky jsou C, Java a C#. O čem to svědčí? O tom, že programátoři neradi píší objektově.
-
Nejoblíbenějšími programovacími jazyky jsou C, Java a C#. O čem to svědčí? O tom, že programátoři neradi píší objektově.
Nepleť si "nejpoužívanější" s "nejoblíbenější".
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
-
Nejoblíbenějšími programovacími jazyky jsou C, Java a C#. O čem to svědčí? O tom, že programátoři neradi píší objektově.
Nepleť si "nejpoužívanější" s "nejoblíbenější".
Blesk je přece také "nejpoužívanější", takže jsi to popletl úplně stejně.
-
Např: Někdo začíná u silně typových jazyků a cítí se omezován, tak přejde na slabě typové. Já naopak čím déle programuji, tím více tíhnu k jasným pravidlům.
Další důležitá vlastnost je vyzrálost jazyka, komunita a množství a kvalita knihoven. Java už je lety prověrená, doplňují se tam víceméně jen nějaké ty lahůdky. Oproti tomu PHP po dvaceti letech dostává funkcionality, které jiná jazyky umí už od začátku.
Vtip je v tom, že PHP/FI už mělo pro svět webu takové praktické funkcionality, ke kterým se ostatní jazyky propracovaly až za 10 let, proto se PHP taky rozšířilo.
PHP má dnes dynamické i statické typování, je možné si vybrat. Podobně je možné si vybrat, zda objekty budou třídní či prototypové. Mohu si vybrat, zda budu programovat špagetově, strukturovaně, funkcionálně či objektově. Vše mohu libovolně kombinovat dle potřeby. Pro někoho to znamená totální chaos, jiný si stanoví pevná pravidla a je v pohodě.
Ano PHP dnes dostává některé funkcionality, které jiné jazyky umí od začátku. Platí to však i naopak. PHP má mnoho vlastností, o kterých si ostatní jazyky nechávají jen zdát.
Multiparadigmatické jazyky jsou zlo, dříve nebo později, systém degraduje na žumpu. Pokud děláš na projektu sám, a dokážeš si to ošéfovat, žádný problém, to samé ale neplatí pro tým 10+ lidí (i míň, i míň ...).
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.
Naproti tomu různých "dokonalých" plátků, které se snažily hlásat "dokonalé" názory už vzniklo a zaniklo spousty.
K tomu by se hodil nějaký výrok pana Nového o autoregulaci, dokonalosti světa a něco o tom, že jedinec ze svého pohledu nemůže činit globální rozhodnutí, protože ty učiní trh.
-
Multiparadigmatické jazyky jsou zlo, dříve nebo později, systém degraduje na žumpu. Pokud děláš na projektu sám, a dokážeš si to ošéfovat, žádný problém, to samé ale neplatí pro tým 10+ lidí (i míň, i míň ...).
Ukaž mi nějaký používaný jazyk, který není multiparadigmatický.
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno.
Řekl bych to jinak: používanost jenom docela volně souvisí s kvalitou jazyka. Primárně rozhoduje to, jestli za jazykem stojí nějaká velká firma -> má peníze natlačit jazyk všude možně -> získá kritickou masu -> pak už se to jenom nabaluje a nabaluje -> pro mamutí devhousy je to výhodný jazyk, protože snadno najdou devs (čti: spotřební materiál) -> goto "pak už se to jenom nabaluje"
Teď třeba něco trochu dělám ve Scale a jsem tím jazykem dost zklamaný. Kdyby byl čistěji funkcionální, mohl být hezký, jednoduchý, příjemný. Ale tím, že chce dodržet interoperabilitu s Javou (viz předchozí odstavec), je to takový dost moloch se spoustou různých těžko pochopitelných pravidel, výjimek,... Třeba s čistotou Elixiru (o Elmu a Haskellu nemluvě) se to vůbec nedá srovnat. Po x letech strávených v Elixiru mě ze Scaly fakt bolí hlava...
...a to všechno kvůli "multiparadigmatičnosti".
-
Ukaž mi nějaký používaný jazyk, který není multiparadigmatický.
Definuj oba pojmy.
-
(...)
Další důležitá vlastnost je vyzrálost jazyka, komunita a množství a kvalita knihoven.
(...)
Tak ať zkusí Perl 5.
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.
No jo, jenže tobě nepřijde metrika pomocí peněz poněkud omezená? Blesk třeba zabaví spoustu lidí pokleslou zábavou. Ale z nikoho to lepšího člověka neudělá (tím bych definoval onu pokleslost). A ve výsledku s těmi lidmi musí spolupracovat i ti, kteří by rádi byli lepší.
S jazykem je to podobné. To, že je jazyk X značně rozšířený je dost blbé, pokud se v něm neprogramuje dobře. Protože to znamená, že v něm budu muset dříve či později programovat i já.
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.
Naproti tomu různých "dokonalých" plátků, které se snažily hlásat "dokonalé" názory už vzniklo a zaniklo spousty.
K tomu by se hodil nějaký výrok pana Nového o autoregulaci, dokonalosti světa a něco o tom, že jedinec ze svého pohledu nemůže činit globální rozhodnutí, protože ty učiní trh.
V Blesku se řeší jenom kdo koho píchá, kdo si nechal zvětšit kozy, kdo umře, kdo umřel, kdo by umřít měl, i když se k tomu nemá a další hromada nesmyslů, drbů a pomluv. I kdyby to vydělávalo miliardy, tak z pohledu kvality obsahu to pořád stojí za obří hovno. Jestli si kromě Blesku nedokážeš představit jinou literaturu, než tu, která hlásá jediný správný názor, tak to už není můj problém.
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.
No jo, jenže tobě nepřijde metrika pomocí peněz poněkud omezená? Blesk třeba zabaví spoustu lidí pokleslou zábavou. Ale z nikoho to lepšího člověka neudělá (tím bych definoval onu pokleslost). A ve výsledku s těmi lidmi musí spolupracovat i ti, kteří by rádi byli lepší.
S jazykem je to podobné. To, že je jazyk X značně rozšířený je dost blbé, pokud se v něm neprogramuje dobře. Protože to znamená, že v něm budu muset dříve či později programovat i já.
Proč by to mělo z někoho dělat lepšího člověka? A co seriály, jak moc vylepší lidi? A co jízda autem? Nebo co venčení psa? Prostě každý má svoje zábavy, tak nevím, co chceš komu zakazovat. Ty si klidně čti jen filozofické knihy a ani radši nechoď do práce. Je to snad nějaký smysl života, abys byl vylepšený? A jak jsi na něj přišel? Někdo chce zůstat tam, kde je a nevadí mu to.
Ne, to neznamená. Stejně tak se nemusíš bavit s pejskaři a nebo čtenáři nějakého deníku. Pokud je máš v práci, tak asi špatná práce, pokud v rodině, asi špatná rodina. Prostě každý má rád něco jiného a pokud má nejvíc lidí rádo Blesk, tak to je fajn, ale to je tak všechno. Jejich volba, kterou ti necpou.
-
Mirek zřejmě naráží na skutečnost, že i ta nejoblíbenější věc může reálně stát za hovno. Argumentovat oblíbeností je dost ošemetné, to je pak takový Michal David PAN zpěvák a geniální textař. Sbíráme céčka, v tom je ta léčka...
Když je něco nejoblíbenější, tak to není na hovno. Blesk je komerční plátek, jeho účelem je vydělávat. Kupuje ho spousta lidí -> plátek vydělává -> dělají to dobře -> není to na hovno.
No jo, jenže tobě nepřijde metrika pomocí peněz poněkud omezená? Blesk třeba zabaví spoustu lidí pokleslou zábavou. Ale z nikoho to lepšího člověka neudělá (tím bych definoval onu pokleslost). A ve výsledku s těmi lidmi musí spolupracovat i ti, kteří by rádi byli lepší.
S jazykem je to podobné. To, že je jazyk X značně rozšířený je dost blbé, pokud se v něm neprogramuje dobře. Protože to znamená, že v něm budu muset dříve či později programovat i já.
Proč by to mělo z někoho dělat lepšího člověka? A co seriály, jak moc vylepší lidi? A co jízda autem? Nebo co venčení psa? Prostě každý má svoje zábavy, tak nevím, co chceš komu zakazovat. Ty si klidně čti jen filozofické knihy a ani radši nechoď do práce. Je to snad nějaký smysl života, abys byl vylepšený? A jak jsi na něj přišel? Někdo chce zůstat tam, kde je a nevadí mu to.
Ne, to neznamená. Stejně tak se nemusíš bavit s pejskaři a nebo čtenáři nějakého deníku. Pokud je máš v práci, tak asi špatná práce, pokud v rodině, asi špatná rodina. Prostě každý má rád něco jiného a pokud má nejvíc lidí rádo Blesk, tak to je fajn, ale to je tak všechno. Jejich volba, kterou ti necpou.
+1
-
Prostě každý má svoje zábavy, tak nevím, co chceš komu zakazovat.
Pointa byla velmi jednoduchá: popularita není dobrým měřítkem kvality. Jak si z toho vydedukoval zakazování, matkopřírodo suď.
Je to snad nějaký smysl života, abys byl vylepšený?
Pro mnoho lidí je rozvoj a vývoj skutečně jednou z hlavních priorit. Pro někoho osobní, pro někoho i společenský.
Někdo chce zůstat tam, kde je a nevadí mu to.
Však to je jeho věc, nikdo mu to nebere.
Prostě každý má rád něco jiného a pokud má nejvíc lidí rádo Blesk, tak to je fajn, ale to je tak všechno.
Pokud má X lidí rádo Blesk, tak to neznamená nic jiného než že X lidem se Blesk trefil do vkusu. Nic víc z toho neplyne.
...jo vlastně ještě jedna věc: pokud se redaktoři chtěli trefit právě do tohoto vkusu a podařilo se jim to, tak jsou profesionálové, kteří dobře umí svoji práci. Což si zasluhuje respekt, pokud to není za cenu nějakých morálních kompromisů.
O kvalitě obsahu to neříká vůbec nic.
-
... tak nevím, co chceš komu zakazovat.
Kdo tady chce komu co zakazovat?
-
Znova... obsah blesku JE kvalitní, protože jeho smyslem není vylepšovat lidi, jeho smyslem je vydělávat peníze a to se mu daří. Nemusí obsahovat fakta, věděcko-teologická pojednání o životě plžů na Marsu, rozbor možností OOP programování v Brainfucku, ani podobné zajímavosti. Prostě je v něm to, co spousta lidí chce, co je na jejich úrovni a za co jsou ochotní tu pětikačku zaplatit (nebo kolik ta sranda stojí).
Zkuste vzít nějakou odbornou literaturu, třeba něco o programování a předložit to nějaké kadeřnici. Až to přečte (jestli vůbec), tak se jí zeptejte, jak se jí to líbilo, jak moc ji to vylepšilo a jestli to považuje za kvalitní knihu.
Je to o základním nepochopení podstaty - Blesk nemá za cíl věnovat se seriózní žurnalistice, jak mnozí od novin očekávají, ale je to prostě bulvár, jeho kvalitu lze posoudit pouze v porovnání s jiným bulvárem a určitě u toho nebude prioritním kritériem etika. Párek taky není méně kvalitní než kladivo, protože s ním nejde zatlouct hřebík.
-
Znova... obsah blesku JE kvalitní, protože jeho smyslem není vylepšovat lidi, jeho smyslem je vydělávat peníze a to se mu daří.
Vydelavat se muze darit i na uplnem nesmyslu. Kdyz budu prodavat krabicku s ledkou pripojenou na baterku, budu to vydavat za "energeticky zaric" a lidi to budou kupovat za pet tisic, cili na jednom kusu vydelam asi tak 4950Kc, tak z toho plyne, ze to je "kvalitni energeticky zaric"?!
Je to o základním nepochopení podstaty - Blesk nemá za cíl věnovat se seriózní žurnalistice, jak mnozí od novin očekávají, ale je to prostě bulvár, jeho kvalitu lze posoudit pouze v porovnání s jiným bulvárem a určitě u toho nebude prioritním kritériem etika. Párek taky není méně kvalitní než kladivo, protože s ním nejde zatlouct hřebík.
Parek je mene kvalitni jidlo nez steak. I kdyby ho pul planety jedlo obden a Kostelecke uzeniny na nem mely marzi 95%.
Zakladni nepochopeni je u tebe: vsichni chapame a uznavame, ze na (pod)prumerne kvalitnim produktu se daji vydelat nadprumerne penize. A uznavame, ze je to dobry (kvalitni) business model. Jenze kvalita business modelu a kvalita produktu jsou dve zcela odlisne veci.
A stejne tak dve zcela odlisne veci jsou kvalita produktu a "vhodnost produktu danemu ucelu". Blesk je jiste vhodny pro masy ctenaru, Java je jiste vhodna pro masy programatoru. To z nich ale NEDELA kvalitni denik a kvalitni programovaci jazyk.
-
Znova... obsah blesku JE kvalitní, protože jeho smyslem není vylepšovat lidi, jeho smyslem je vydělávat peníze a to se mu daří.
Buřty z pilin jsou kvalitní, protože jejich smylem je vydělávat prachy a to se jim daří?
-
pokud se bavíte o kvalitě, tak je nutné mluvit i o kritériích, jinak se moc nedomluvíte
-
Ano, párek, nebo třeba buřt z pilin může být kvalitní produkt, protože si ho spousta lidí může dovolit každý den a každý den je kvalitně zasytí za řádově méně peněz, než steak, který by si spousta lidí každý den dovolit nemohla, takže by měli hlad. Dokonce se dají nacpat éčkama tak, až jim bude slupka praskat a budou mít úžasnou glutamátovou chuť, takže pro spousty lidí je i požitek z jídla kvalitní. Pokud jako měřítko kvality vezmeme zdravotní aspekty, pak už na tom bude pravděpodobně s kvalitou hůř.
U věcí nemateriálních je to s kvalitou složitější. Týká se to novin, knih, hudby, umění obecně... tam je to o vkusu a kvalitu může posoudit pouze někdo, kdo je cílovou skupinou daného produktu. Pro mě je Blesk něco, co si nekupuji, protože mě bulvár nezajímá, preferuji "čisté" informace, ve kterých mi nejsou podsouvány cizí názory a představy, protože ty si raději tvořím sám. Na druhou stranu, tchýně si Blesk kupuje a jakožto přečtený odpad se pro mě stává kvalitním materiálem na podpal.
-
Teď třeba něco trochu dělám ve Scale a jsem tím jazykem dost zklamaný. Kdyby byl čistěji funkcionální, mohl být hezký, jednoduchý, příjemný.
Co konkrétně myslíte tím čistěji funkcionální? Narážíte na klasické stížnosti např. z We're Doing It All Wrong by Paul Phillips (https://www.youtube.com/watch?v=TS1lpKBMkgg)?
Ale tím, že chce dodržet interoperabilitu s Javou (viz předchozí odstavec), je to takový dost moloch se spoustou různých těžko pochopitelných pravidel, výjimek
Myslím, že interoperabilita s Javou není ten hlavní důvod (řekl bych, že důvodem byla absence teoretických základů a fakt, že chování některých vlastností jazyka nebylo dostatečně prozkoumáno v době, kdy se do jazyka dostaly). Třeba Dotty (v podstatě nová verze Scaly) je v některých ohledech čistší než Scala.
Třeba s čistotou Elixiru (o Elmu a Haskellu nemluvě)
Jenže Elm je výrazně jednodušší jazyk, který má v mnoha ohledech o dost horší vyjadřovací schopnosti (např. nemá higher-kinded typy, nemá makra, nemá typové třídy, nemá podtypový polymorfismus).
Hlavní problém Haskellu je seq, který řadu věcí komplikuje a jehož důsledkem je, že řada teoretických výsledků pro Haskell neplatí. GHC Haskell mi jako ideál čistoty nepřijde - obsahuje řadu netriviálních rozšíření, jejichž funkcionalita se všelijak překrývá a pro některé kombinace rozšíření nikdo nikdy nezkoumal, jak se chovají dohromady.
-
Co konkrétně myslíte tím čistěji funkcionální? Narážíte na klasické stížnosti např. z We're Doing It All Wrong by Paul Phillips (https://www.youtube.com/watch?v=TS1lpKBMkgg)?
Tuhle prednasku jsem nevidel, snad najdu cas na ni v brzke dobe kouknout a dam vedet.
Ted momentalne jsem myslel to, ze se ve Scale (z meho pohledu) uplne zbytecne resi nejake tridy. A z toho plyne spousta vyjimek. Napr. mezi sebou nemuzou dedit case classes. Zadnou logiku to (z pohledu novacka) nedava, je potreba si to zapamatovat.
Myslím, že interoperabilita s Javou není ten hlavní důvod (řekl bych, že důvodem byla absence teoretických základů a fakt, že chování některých vlastností jazyka nebylo dostatečně prozkoumáno v době, kdy se do jazyka dostaly). Třeba Dotty (v podstatě nová verze Scaly) je v některých ohledech čistší než Scala.
To je mozne, fakt se s tim jazykem teprve seznamuju, takze pisu o prvnich dojmech, ne o nejakem hlubokem vhledu. Zatim se z meho pohledu jazyk zbytecne komplikuje tim, co jsem psal vys: ze vubec obsahuje tridy, ktere jsou z pohledu "klasickeho funkcionalniho programovani" dost zbytecne.
Jenže Elm je výrazně jednodušší jazyk, který má v mnoha ohledech o dost horší vyjadřovací schopnosti (např. nemá higher-kinded typy, nemá makra, nemá typové třídy, nemá podtypový polymorfismus).
Ano, to je urcite pravda. Elm je cisty a jednoduchy za cenu mensi sily. Scala je silna a interoperabilni za cenu komplikovanosti.
Napr. obcas mi prekladac pise neco v tom stylu, ze u nejake lambdy potrebuje plne otypovani (omlouvam se, priklad ted narychlo nevymyslim) - proc, to nedokazu odhalit. Nepochybne je to jenom moje neznalost, ale to je prave spatne, ze je jazyk tak komplikovany, ze nejsem schopny predvidat, co prelozi a co ne.
Dalsi vec, kterou vubec nechapu, je nemoznost destrukturovat slozene typy primo v hlavicce fce. Napr. tohle (kod pro http://flink.apache.org/) je proste zhovadilost:
stream
.map((x) => x match { case (t,v) =>
s"${t}: ${v}"
})
.print
za naprostou samozrejmost bych povazoval zapis
stream
.map( (t,v) => s"${t}: ${v}" )
.print
...to jenom tak pro priklad, je toho daleko vic... prakticky na kazdem kroku narazim na neco, u ceho vubec nechapu, proc je to tak, jak to je... A to proste neni dobre.
-
Dalsi vec, kterou vubec nechapu, je nemoznost destrukturovat slozene typy primo v hlavicce fce. Napr. tohle (kod pro http://flink.apache.org/) je proste zhovadilost:
stream
.map((x) => x match { case (t,v) =>
s"${t}: ${v}"
})
.print
Nešlo by napsat následující?
stream
.map { case (t,v) => s"$t: $v" }
.print
-
Nešlo by napsat následující?
stream
.map { case (t,v) => s"$t: $v" }
.print
Neslo. To je prave ten pripad, co jsem psal, ze me ted nenapada priklad. Kompiler mi rekne:
Error:(150, 12) missing parameter type for expanded function
The argument types of an anonymous function must be fully known. (SLS 8.5)
Expected type was: ?
.map { case (t,v) => s"$t: $v" }
...a pritom kdyz tam pridam to "(x) => x match", tak mu taky zadny typ nerikam a prelozi to. Je to pro me naprosto nepochopitelny chovani.
-
Neslo. To je prave ten pripad, co jsem psal, ze me ted nenapada priklad. Kompiler mi rekne:
Error:(150, 12) missing parameter type for expanded function
The argument types of an anonymous function must be fully known. (SLS 8.5)
Expected type was: ?
.map { case (t,v) => s"$t: $v" }
...a pritom kdyz tam pridam to "(x) => x match", tak mu taky zadny typ nerikam a prelozi to. Je to pro me naprosto nepochopitelny chovani.
Flink neznám, ale nepomůže https://ci.apache.org/projects/flink/flink-docs-release-1.1/apis/scala_api_extensions.html#accept-partial-functions ?
-
Flink neznám, ale nepomůže https://ci.apache.org/projects/flink/flink-docs-release-1.1/apis/scala_api_extensions.html#accept-partial-functions ?
To uz jsem taky zkousel a nefunguje mi to. Kdyz pridam
import org.apache.flink.streaming.api.scala.extensions._
tak ta chyba nezmizi a ten import radek se v Idea zobrazuje sede (nevyuzity import). Pritom mam Fink 1.1.1, u ktereho by to melo fungovat. Tak nevim.
Ale spis mi slo o princip: prekladac si stezuje na to, ze nezna typ. Kdyz pred ten vyraz dam nejakou obalku, ktera mu typ taky nesdeluje, tak je najednou v pohode. A spravit by se to melo nejakym importem nevim ceho. To se mi fakt nelibi, kdyz vubec netusim, co prekladac dela... A na tyhle veci proste narazim porad :(
-
Ale spis mi slo o princip: prekladac si stezuje na to, ze nezna typ. Kdyz pred ten vyraz dam nejakou obalku, ktera mu typ taky nesdeluje, tak je najednou v pohode.
Chápu. Potíž je v tom, že obě konstrukce se trochu liší (jsou popsány i v různých částech specifikace - jedna v 6.23, druhá v 8.5).
A spravit by se to melo nejakym importem nevim ceho.
Ten import přidá novou funkci mapWith, která nemá různé overloady (původní map má minimálně 2), tj. kompilátor snáze uhodne typ.
-
Chápu. Potíž je v tom, že obě konstrukce se trochu liší (jsou popsány i v různých částech specifikace - jedna v 6.23, druhá v 8.5).
No a jsme u toho... Vyjimky, speciality, vyjimky z vyjimek a specialni vyjimky ze specialit... :)
Ten import přidá novou funkci mapWith, která nemá různé overloady (původní map má minimálně 2), tj. kompilátor snáze uhodne typ.
Aha. Takze hnusny hack na neco, co bych ocekaval, ze bude fungovat samo od sebe...
-
Chápu. Potíž je v tom, že obě konstrukce se trochu liší (jsou popsány i v různých částech specifikace - jedna v 6.23, druhá v 8.5).
No a jsme u toho... Vyjimky, speciality, vyjimky z vyjimek a specialni vyjimky ze specialit... :)
Jj, třeba Haskell a Elm mají AFAIK pouze jeden typ funkcí, Scala jich má několik (např. funkce, parciální funkce, ...).
Ten import přidá novou funkci mapWith, která nemá různé overloady (původní map má minimálně 2), tj. kompilátor snáze uhodne typ.
Aha. Takze hnusny hack na neco, co bych ocekaval, ze bude fungovat samo od sebe...
Je to blbě navržené API. Obecně jazyky s dobrou typovou inferencí mají dobrý důvod, proč nemít overloading (vede to na explozi možností, které kompilátor musí uvažovat - jeden z důvodů, proč Scala nemá dobrou typovou inferenci).
-
Je to blbě navržené API.
Nemyslím, že blbě. Je to tak nejspíš proto, aby bylo API společné pro Javu i Scalu - a scalovské speciality byly jenom jako plus bokem.
Obecně jazyky s dobrou typovou inferencí mají dobrý důvod, proč nemít overloading (vede to na explozi možností, které kompilátor musí uvažovat - jeden z důvodů, proč Scala nemá dobrou typovou inferenci).
Jo. A je to další konkrétní příklad komplikace, kterou má Scala kvůli interoperabilitě s Javou.
-
Je to blbě navržené API.
Nemyslím, že blbě. Je to tak nejspíš proto, aby bylo API společné pro Javu i Scalu - a scalovské speciality byly jenom jako plus bokem.
Já myslím, že ano, protože ve Sparku to funguje dobře (v Javě 8 i Scale) - tam overloading nepoužili.
Jo. A je to další konkrétní příklad komplikace, kterou má Scala kvůli interoperabilitě s Javou.
Jj, tohle je dobrý příklad - overloading dost komplikuje jazyk.
-
Já myslím, že ano, protože ve Sparku to funguje dobře (v Javě 8 i Scale) - tam overloading nepoužili.
A k jakemu presne problemu tam dochazi? Snazim se to z API nejak vydedukovat, ale pusto, prazdno, temno... :)
Flinkovske API je
public <R> DataStream<R> map(scala.Function1<T,R> fun,
TypeInformation<R> evidence$6)
public <R> DataStream<R> map(MapFunction<T,R> mapper,
TypeInformation<R> evidence$7)
https://ci.apache.org/projects/flink/flink-docs-release-1.1/api/java/org/apache/flink/streaming/api/scala/DataStream.html#map-scala.Function1-org.apache.flink.api.common.typeinfo.TypeInformation-
...a to Sparkovske mi prijde uplne stejne:
def map[U](func: MapFunction[T, U], encoder: Encoder[U]): Dataset[U]
def map[U](func: (T) ⇒ U)(implicit arg0: Encoder[U]): Dataset[U]
http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.sql.Dataset
-
Ta diskuse o kvalitě na příkladu Blesku mne zaujala.
Jen mne překvapilo, že nikdo nezmínil Windows. Z tohoto pohledu jsou Windows extrémně kvalitní produkt, poněvadž jejich podílu na trhu se třeba Blesk ani zdálky nepřiblížil. Tak potom nevím, na co si tady v diskusích všichni stěžují, jak Win stojí za prd...
-
Ta diskuse o kvalitě na příkladu Blesku mne zaujala.
Jen mne překvapilo, že nikdo nezmínil Windows. Z tohoto pohledu jsou Windows extrémně kvalitní produkt, poněvadž jejich podílu na trhu se třeba Blesk ani zdálky nepřiblížil. Tak potom nevím, na co si tady v diskusích všichni stěžují, jak Win stojí za prd...
+1
-
Já myslím, že ano, protože ve Sparku to funguje dobře (v Javě 8 i Scale) - tam overloading nepoužili.
A k jakemu presne problemu tam dochazi? Snazim se to z API nejak vydedukovat, ale pusto, prazdno, temno... :)
Flinkovske API je
public <R> DataStream<R> map(scala.Function1<T,R> fun,
TypeInformation<R> evidence$6)
public <R> DataStream<R> map(MapFunction<T,R> mapper,
TypeInformation<R> evidence$7)
https://ci.apache.org/projects/flink/flink-docs-release-1.1/api/java/org/apache/flink/streaming/api/scala/DataStream.html#map-scala.Function1-org.apache.flink.api.common.typeinfo.TypeInformation-
...a to Sparkovske mi prijde uplne stejne:
def map[U](func: MapFunction[T, U], encoder: Encoder[U]): Dataset[U]
def map[U](func: (T) ⇒ U)(implicit arg0: Encoder[U]): Dataset[U]
http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.sql.Dataset
U Sparku jsem myslel na RDD třídy (kde je skutečně jen jedna metoda map). Tady u Datasetu se obě metody liší počtem parametrů (první má 2, druhá má 1) - když předáte pouze funkci, kompilátor Scaly snadno pozná, že chcete volat tu druhou metodu s jedním parametrem (když ví, jakou metodu chcete volat, použije typ parametru metody, k určení typu anonymní funkce).
Zatímco u Flinku ve Scale je situace jiná (vy se koukáte na Flink v Javě):
def map[R](fun: (T) ⇒ R)(implicit arg0: TypeInformation[R], arg1: ClassTag[R]): DataSet[R]
def map[R](mapper: MapFunction[T, R])(implicit arg0: TypeInformation[R], arg1: ClassTag[R]): DataSet[R]
Obě metody ve Flinku mají jeden parametr - na rozdíl od Sparku kompilátor k jejich odlišení musí použít typ prvního argumentu (jenže ten zatím nezná).
Rozdíl je tedy v tom, že Flink má dvě metody map s jedním parametrem a Spark jen jednu.
-
Tady u Datasetu se obě metody liší počtem parametrů (první má 2, druhá má 1)
No ale ta s jednim ma zas druhy implicitni - takze kompilator musi taky resit, jestli jsem ho nepredal, ne?
(Anebo ten zapis zas nechapu, to je klidne mozny :) )
vy se koukáte na Flink v Javě):
def map[R](fun: (T) ⇒ R)(implicit arg0: TypeInformation[R], arg1: ClassTag[R]): DataSet[R]
def map[R](mapper: MapFunction[T, R])(implicit arg0: TypeInformation[R], arg1: ClassTag[R]): DataSet[R]
Odkud je tohle? Ve scalovskem api DataStream vubec nevidim: https://ci.apache.org/projects/flink/flink-docs-release-1.1/api/scala/index.html
-
Tady u Datasetu se obě metody liší počtem parametrů (první má 2, druhá má 1)
No ale ta s jednim ma zas druhy implicitni - takze kompilator musi taky resit, jestli jsem ho nepredal, ne?
Ta první metoda
def map[U](func: MapFunction[T, U], encoder: Encoder[U]): Dataset[U]
jde zavolat pouze map(f, e).
Zatímco druhou metodu
def map[U](func: (T) ⇒ U)(implicit arg0: Encoder[U]): Dataset[U]
jde volat map(f)(e) nebo map(f) nebo map { f } (e) nebo map { f } atd. Společené je to, že první seznam argumentů obsahuje vždy jeden argument (u první metody první seznam argumentů obsahuje vždy dva argumenty).
Tj. když napíšete
.map { case (x, y) => ??? }
tak je kompilátoru jasné, že voláte tu druhou metodu, neboť první seznam argumentů obsahuje jeden argument.
Odkud je tohle? Ve scalovskem api DataStream vubec nevidim: https://ci.apache.org/projects/flink/flink-docs-release-1.1/api/scala/index.html
To jsem omylem okopíroval z DataSetu - DataStream tam také nevidím.
-
tak je kompilátoru jasné, že voláte tu druhou metodu, neboť první seznam argumentů obsahuje jeden argument.
Aha, už je mi to jasné (snad ;) ). Tyhlety vícenásobné seznamy parametrů, to je taky lahůdka, se kterou jsem se ještě nestihl pořádně seznámit :) Děkuju za výsvětlení!
...no každopádně myslím, že sice silný offtopic, ale jako ilustrace, proč mi přijde Scala zbytečně překombinovaná oproti "normálním" funkcionálním jazykům, to posloužilo dobře :)