Co se naučit (diskuse)

[Gilhad]

Ja treba pouzivam uz radu let Python jako hlavni programovaci jazyk a vypada to, ze v tom budu i nadale pokracovat. (samozrejme pouzivam trochu i dalsi, jako bash, C, systemove nastroje ... ale to je spis takova bizuterie okolo)

[JS]

A co v tom delas?

(Ja to casto pouzivam na vedlejsi veci, ruzne skriptiky v praci.)

[xxar3s]

Skus F# tu je par video-tutorialov od Tomasa Petricka:

http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-I
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-II
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-III
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-IV

[Bystroushaak]

F#? To nic hipsterštějšího by nebylo?

PS: Bylo, já se teď snažím pochopit rebol :D

[Ivorne]

No vzhledem že to je od Microsoftu to zas taková hipsteřina nebude. :D

[Gilhad]

A v cem by mi to melo pomoct?

Python je v Gentoo nativne, nemusim delat nejake opicarny s emulaci MS platforem a mam v nem uz spoustu knihoven. Navic nevim, jak moc efektivni jsou postupy z tech videi, ale prijde mi, ze se snazi najit nejnevhodnejsi cestu, jak neco naprogramovat.

AggregateNumbers treba misto for cyklu pouziva rekurzi - tedy pro milion hodnot bude milionkrat volat sebe sama, jen aby se vyhnula prirazeni do promenne - i pokud to nespadne na nedostatek pameti, tak silne pochybuju o tom, ze by to dopocitalo v nejakem rozumnem case.

Jako jo, je to zajimava hracka, stejne jako kdyz jsem v Karlovi nadefinoval scitani dlouhych cisel. Ale pro prakticke pouziti to je silenost.

[deda.jabko]

AggregateNumbers treba misto for cyklu pouziva rekurzi - tedy pro milion hodnot bude milionkrat volat sebe sama, jen aby se vyhnula prirazeni do promenne - i pokud to nespadne na nedostatek pameti, tak silne pochybuju o tom, ze by to dopocitalo v nejakem rozumnem case.

seda je teorie, ... inteligentni prekladac to prevede na cyklus, gcc bezne tail cally prevadi na cyklus uz s -O1 a slozitejsi rekurzi s -O2

[xxar3s]

Presne ako pise deda.jabko, rekurzivne volania sa prevadzaju na cykly (ak je rekurzivna funkcia spravne napisana).

http://thevalerios.net/matt/2009/01/recursion-in-f-and-the-tail-recursion-police/ F# neni ziadny akademicky experiment, je to realne pouzivany jazyk bezne sa pouziva u trading apps. Vykon je +- rovnaky ako u C#.

[JS]

Ja bych asi volil podle projektu.. Pokud mas neco, co chces naprogramovat ve volnem case, proc si nevybrat jazyk podle toho?

Pokud jsi s PHP (a svoji dosavadni karierou) spokojeny, nevidim v tom problem. Ve skutecnosti dost zamestnavatelu ocenuje i ochotu se naucit novou vec, konkretne kterou je detail.

Jina vec je, ze bych ten seznam moznych jazyku trochu rozsiril: Common Lisp, Go, Racket, Clojure, Haskell, Perl6, OCaml, Prolog, Forth, Verilog/VHDL.. Vsechno zajimave moznosti, zalezi, cemu se chces venovat.

[JS]

Ah, spatne jsem to pochopil.. Myslel jsem, ze hledas hobby technologii, a ty hledas nejakou pro praci.

[Dát smazat]

Tak nějak, zatím mám PHP na úrovni co stačí tady.. ale až budu chtít změnit práci byl bych nerad aby se ukázalo, že to nestačí na práci jinde.

Pokud jde o "hobby" činnost tak fotím, rád dělám weby a spravuju 3 linuxové servery (dva webové a jeden backup). Zkrátka ve volném čase nouzi o aktivitu nemám.

[dementni.lojzik]

a ty hledas nejakou pro praci.

a proto by si mel vybrat jazyk podle prace Vyber si firmu kde chces delat a podle toho se nauc jazyk/jazyky, ktere tam budes potrebovat

[Ivorne]

Za mě určitě C++. Oproti ostatním zmiňovaným tě to naučí i něco navíc než jen syntaxi daného jazyka. Že by jeho důležitost opadala bych se bál nejméně ze všech zmíněných jazyků. Je pravdou, že v oblastech, pro které není C++ vhodné, je zastupováno novými jazyky, ale existuje řada oblastí, pro kterou je velmi vhodné.

C++ není navíc tak zprasené jako C# nebo Java, kde musíte pořád přemýšlet, co se asi tak honilo tvůrcům jazyka hlavou při navrhování jazyka, ale soustředíte se jen na to, co chcete udělat. Navíc když si dáte pozor na výběr knihoven, tak je i více multiplatformní.

Asi to zabere déle času na naučení, ale zase vám to pomůže pochopit i další programovací jazyky. A jak říkám, myslím si, že C# a Java zaniknou dříve než C++.

[Člověk z Horní Dolní]

C++ je (spolu s Pascalem) jazyk, kterému se snažím za každou cenu vyhnout. Je to takový divný a složitý kočkopes, vzali C a připlácli k tomu pár věcí z vyskoúrovňových jazyků. C a Java jsou oproti C++ krásně jednoduchý, zaměřují se jenom na jednu úroveň abstrakce.

Java není špatná, a C# je vylepšená Java. Na větší projekty (kde není nutný použít C++ kvůli rychlosti nebo existujícímu kódu) nemají tyhle jazyky velkou konkurenci.

[Ivorne]

Co je na Javě jednoduchého? V tom GC se nikdo nevyzná (aspoň nikoho neznám), každá třída má tunu metod a předchůdců a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelně.

[Člověk z Horní Dolní]

Co je na Javě jednoduchého?

Oproti C++ všechno :) Syntaxe mi nepřijde složitější než ta co má Python nebo Ruby.

V tom GC se nikdo nevyzná (aspoň nikoho neznám)

Co to znamená vyznat se v GC? Jako vyznat se v tom, jak to je implementovaný?

každá třída má tunu metod a předchůdců

Hm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...

a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelně

Například? (neříkám, že tam nejsou)

[Ivorne]

každá třída má tunu metod a předchůdců

Hm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...

Nov STL moc metod není. V rodičích je trochu těžké se vyznat zvláště kvůli použití template, ale má to svůj význam.

V tom GC se nikdo nevyzná (aspoň nikoho neznám)

Co to znamená vyznat se v GC? Jako vyznat se v tom, jak to je implementovaný?

No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.

a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelně

Například? (neříkám, že tam nejsou)

Tak třeba díky nepředvídatelnosti GC je metoda finalize vpodstatě zbytečná. Dokážu si představit velmi malé množství případů, kdy její použití není návrhovou chybou.

Proč je Interface něco jiného než abstraktní třída? Je to proto, že Java neumožňuje dědit po více třídách najednou. Jenže pak ten interface není potomkem Objektu i přes to, že každý objekt v Javě musí být potomkem Objektu. Už si nepamatuju, jak se to řeší, ale není to zrovna elegantní.

Jazyk na té úrovni, na které se Java snaží mít, by měl mít přetěžování operátorů. Java se tváří, že je hrozně 'oběktově orientovaná', ale bez přetěžování operátorů a bez vícenásobné dědičnosti a dalších věcí to za moc nestojí.

[Radek Miček]

No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.

A v C++ to musíte zajistit ručně, což mi přijde ještě méně spolehlivé, když vás nic nehlídá, zda to opravdu uděláte.

[Ivorne]

Pokud neumíte základy správy paměti, tak vás ani GC nezachrání.

[Agent]

C++ obsahuje něco jako strážce pointerů - std::auto_ptr a std::shared_ptr a možná další, pak je správa paměti automatická. Dobrý C++ program si vše uklízí sám, jak paměť, tak zdroje aniž by se o to programátor jakkoli ručně staral. Je to asi lepší, než napůl cesty gc v Javě, který uklidí paměť, ale nechává viset zabrané zdroje programu.

[Radek Miček]

C++ obsahuje něco jako strážce pointerů - std::auto_ptr a std::shared_ptr a možná další, pak je správa paměti automatická.

Tohle je dost neefektivní (běžný GC bude rychlejší – viz třeba Deutsch-Bobrow) a navíc to nefunguje v přítomnosti cyklů.

Je to asi lepší, než napůl cesty gc v Javě, který uklidí paměť, ale nechává viset zabrané zdroje programu.

GC může při finalizaci uvolnit i zdroje, akorát to není deterministické.

[kralyk z abclinuxu]

Tohle je dost neefektivní (běžný GC bude rychlejší – viz třeba Deutsch-Bobrow)

[citation needed], to je hodně divoké tvrzení. Krom toho C++ smart pointery typicky není problém použít způsobem podobným jako Deutsch-Bobrow. Říká ti něco RAII?

a navíc to nefunguje v přítomnosti cyklů

Od toho je std::weak_ptr. Ale imho je lepší se cyklům vyhnout už při návrhu, pokud možno samozřejmě.

[Radek Miček]

[citation needed], to je hodně divoké tvrzení.

Proč myslíte?

Chytré ukazatele odpovídají počítání referencí. Počítání referencí s DB je typicky rychlejší než klasické počítání referencí. Moderní GC, např. ten v JVM, je typicky rychlejší než DB.

Empiricky: Boost's shared_ptr up to 10× slower than OCaml's garbage collection

Krom toho C++ smart pointery typicky není problém použít způsobem podobným jako Deutsch-Bobrow.

A jak je takové řešení bezpečné?

Říká ti něco RAII?

Na co narážíte?

[kralyk z abclinuxu]

Chytré ukazatele odpovídají počítání referencí.

Obecně ne. Chytrý ukazatel std::unique_ptr slouží k vlastnění objektu jedním vlastníkem, a tudíž nepotřebuje počítání (totéž jeho ekvivalent boost::scoped_ptr a starší, nebezepečná varianta std::auto_ptr také nepočítá reference).

Počítání referencí s DB je typicky rychlejší než klasické počítání referencí.

Pro nějaké definice "klasického počítání referencí" určitě...

Empiricky: Boost's shared_ptr up to 10× slower than OCaml's garbage collection

Vůbec nechápu smysl toho benchmarku. Proč autor porovnává shared_ptr a GC? A co to vůbec znamená, jak to porovnává? Míchá jablka a hrušky. Dělá to na mě dojem, že vzali kód, který používal malloc+free, a nahradili veškeré alokace instancí shared_ptr. Pokud ano, tak není divu, že výsledek je pomalý. K tomu shared_ptr ale není určený. Nasazení RAII v doposud non-RAII C++ programu bude typicky vyžadovat trochu víc než jen nahrazení alokací, spíš celkovou změnu návrhu.

Na co narážíte?

Na to, že reference counting se typicky použije pouze v případech, kdy to je nutné. V C++ memory managementu je v naprosté většině případů snaha počítání referencí minimalizovat a použít jiné metody (stack-based memory management, move semantics,...).

[Radek Miček]

Vůbec nechápu smysl toho benchmarku. Proč autor porovnává shared_ptr a GC? A co to vůbec znamená, jak to porovnává? Míchá jablka a hrušky. Dělá to na mě dojem, že vzali kód, který používal malloc+free, a nahradili veškeré alokace instancí shared_ptr. Pokud ano, tak není divu, že výsledek je pomalý. K tomu shared_ptr ale není určený.

To se vracíme k mé původní výtce, tj., že ruční správa paměti není spolehlivá. Ptám se tedy, jak se v C++ spravuje paměť a zdroje, aby to bylo spolehlivé?

Na to, že reference counting se typicky použije pouze v případech, kdy to je nutné. V C++ memory managementu je v naprosté většině případů snaha počítání referencí minimalizovat a použít jiné metody (stack-based memory management, move semantics,...).

Díky za upřesnění. Ale opět to v C++ není spolehlivé. Třeba v Rustu to spolehlivé je, neboť tam to garantuje typový systém. Podobně v ATS.

Pro nějaké definice "klasického počítání referencí" určitě...

Počítá se každá reference.

[kralyk z abclinuxu]

Ale opět to v C++ není spolehlivé.

Tak určitě to je výrazně spolehlivější než čistě ruční alokování + dealokování (které je kritizováno v té původní výtce, jestli to dobře chápu), zejména když se používají výjimky. Pokud člověk dodrží příslušná pravidla, mělo by to být celkem rozumně spolehlivé. Ale jinak C++ určitě není známé tím, že by se nějak moc staralo o programátorovu bezpečnost

[chytrák]

Evidentně vůbec nevíš o čem mluvíš. Fungování GC je jasně popsané a pochopí to snad každý, kdo má aspoň minimum zkušeností s programováním. Finalize pokud vím není ve standardí knihovně snad nikde použité, je to pouze jedna z metod třídy se speciálním významem (který jak píšeš nemá moc význam). Interface není objekt, leží úplně mimo, neobsahuje implementace metod, takže nedefinuje chování, ale pouze rozhraní. Třeba při použití interface se volá metoda pomocí instrukce invokeInterface a ne inistrukcí invokeVirtual. Implementace interface potomkem objektu být musí. Vícenásobná dědičnost obvykle přináší víc problémů než kolik jich řeší, a tak se v moc jazycích nevyskytuje.

Objektově orientovaný jazyk vůbec přetěžování operátorů mít nemusí. Dokonce nemusí mít operátory vůbec(např. scala). Java je jazyk, který řeší složitost pomocí knihoven (stejně jako třeba C), C++ je jazyk, který řeší složitost speciálními konstrukcemi jazyka (přetěžování operátorů, implicitní konverze atd.). Každý přístup má svoje výhody a nevýhody.

[Ivorne]

Co myslíš tím, že scala nemá operátory?

[chytrák]

Metodu si můžeš pojmenovat jak chceš, to znamená např. "+". Její volání je možné místo tečkové notace a závorek provádět pomocí mezery takže místo 1.+(1) napíšeš 1 + 1 a je to ekvivalentní. Vypadá to jako operátor +, ale ve skutečnosti se jedná o volání metody plus. Takže můžeš mít "operátor" z libovolného znaku nebo textového řetězce, který má jeden parametr.

[Ivorne]

Takže ve scale se klidně může stát, že 'a + b' je korektní přákaz, ale 'a+b' buď udělá něco jiného nebo to bude syntax chyba? To mi zní docela šíleně.

[chytrák]

V případě znaků jako plus tam ta mezera být nemusí. Ale je pravda že to potom může být matoucí. Výraz 1.+(1) by se dal interpretovat jako (double)1 + (1).

[Ivorne]

Zajímavé, hezké. Spíše než "scala nemá operátory" bych tento fenomén definoval jako "scala má přetěžování operátorů".

[frEon]

jak tam resej 1 + 1 / 3 ?

[Luboš Doležel (Doli)]

Finalize pokud vím není ve standardí knihovně snad nikde použité, je to pouze jedna z metod třídy se speciálním významem (který jak píšeš nemá moc význam).

finalize() se musí používat všude tam, kde se používají nějaké nativní popisovače apod. Takže aby třeba došlo k zavření souboru, pokud programátor nevolá close() sám. A to v té std. knihovně párkrát bude, ne?

[Člověk z Horní Dolní]

Hm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...

Nov STL moc metod není. V rodičích je trochu těžké se vyznat zvláště kvůli použití template, ale má to svůj význam.

Mel jsem na mysli spis standardni knihovnu javy, stl moc neznam.

No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.

To je vetsinou všechno co je potreba vedet - dokud mas nekde odkaz na objekt, tak ten dokaz zustane v pameti.

Proč je Interface něco jiného než abstraktní třída? Je to proto, že Java neumožňuje dědit po více třídách najednou. Jenže pak ten interface není potomkem Objektu i přes to, že každý objekt v Javě musí být potomkem Objektu. Už si nepamatuju, jak se to řeší, ale není to zrovna elegantní.

Nevim co tim presne myslis, ale nejde vytvorit instanci interfacu. Jenom instanci tridy, takze kazda instance musi byt potomkem Objectu.

Vicenasobna dedicnost neni neco co bych potraboval kazdy den, ale nevadilo by mi, kdyby ji do Javy pridali (nebo traity).

Pretezovani operatoru a spoustu dalsich veci bych si v Jave taky pral... Java ma od idealniho jazyka hodne daleko, ale je relativne rychla, ma skvelou integraci s ide vcetne staticky analyza kodu a spoustu knihoven. Pro hodne problemu je Java dobra volba. C++ je sice o neco rychlejsi, ale imho to je min produktivni jazyk.

[chytrák]

O traitech se mluví v souvislosti s Javou 8. Měli by být povolené default implementace metod v interfacech. Celé se to zavádí kvůli zachování zpětné kompatibility při použití anonymních funkcí ve stávající standardní knihovně. Jinak by se museli měnit interface List apod.

Do traitů ze scaly to ale má hodně daleko, protože stále nemůžeš definovat proměnné, takže v té metodě můžeš pouze volat další metody z interface. Vzniká tím problém vícenásobné dědičnosti, ale nečetl jsem jak to má být řešené (ve scale to je linearizací stromu dědičnosti).

[Člověk z Horní Dolní]

O to víc mě mrzí, že Android má jenom Javu 6 a nevypadá to, že by se to mělo v dohledné době změnit...

[Ivorne]

A nebudou u traitů vznikat ty samé problémy jako jsou u vícenásobné dědičnosti? Nějak přestávám chápat, jaký je nakonec rozdíl mezi traity a třídami.

[x]

Ne. Jediny problem s vicenasobnou dedicnosti je inicializace, a ta u traitu neni (traity nemaji konstruktory).

[x]

Traity ve Scale jsou ve skutecnosti mixiny (linearizace, ...). Defaultni implementace metod v Jave 8 jsou bezestavove traity.

[Člověk z Horní Dolní]

finalize() je de facto zbytecna, doporucuje se tuhle metodu nepouzivat.

[x]

A dokonce nebezpecna (viz JDBC...).

[luky]

a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelně

Například? (neříkám, že tam nejsou)

Neudrzuji zpetnou kompatibilitu na urovni syntaxe. To je nejvetsi hnus, co muze nekdo s jazykem udelat.

[Radek Miček]

To je problém skoro všech jazyků. C++11 třeba přidalo nová klíčová slova, čímž porušilo zpětnou kompatibilitu na úrovni syntaxe.

V tomto ohledu je na tom docela dobře jazyk Standard ML '97, který se od roku 1997 nezměnil, a přesto jeho vyjadřovací schopnosti příliš nezaostávají za moderními programovacími jazyky. A navíc je to IMO jeden z nejlepších jazyků na výuku programování.

[luky]

Tak treba v C s tim problem neni, protoze pridana klicova slova zacinaji na podtrzitko (namespace vyhrazeny pro platformu) a v nove pridane hlavicce je potom #define na verzi bez podtrzitka, takze se nerozbije starej kod.

[Bystroushaak]

Za mě určitě C++. Oproti ostatním zmiňovaným tě to naučí i něco navíc než jen syntaxi daného jazyka.

To jo. Třeba ocenit, že u ostatních se při návrhu i přemýšlelo :)

C++ není navíc tak zprasené jako C# nebo Java, kde musíte pořád přemýšlet, co se asi tak honilo tvůrcům jazyka hlavou při navrhování jazyka, ale soustředíte se jen na to, co chcete udělat.

:D

[Radek Miček]

zase vám to pomůže pochopit i další programovací jazyky

Možná to platí pro jazyky odvozené z C++, ale obecně o tom pochybuji. Základní koncepty jsou totiž v C++ velmi omezeny a splácány dohromady.

[patlal]

C++ není navíc tak zprasené jako C# nebo Java, kde musíte pořád přemýšlet, co se asi tak honilo tvůrcům jazyka hlavou při navrhování jazyka, ale soustředíte se jen na to, co chcete udělat.

Myslíš to C++, o kterém jeho autor prohlásil něco v tom smyslu, že neočekává,že by ho někdo pochopil celé?

[Sten]

Jj, v aprílovém rozhovoru

[Dreit]

D?

[xxxxxxxxxxxxxxxx]

Na placenou praci IMO ne.

[vlastikroot]

Na komercni vyuziti je super C++. Takovy clovek se uzije skoro vsude Ja treba delam hlavne Qt/C++, umim vicemene jen zaklady, ale na firemni databazove aplikace je to super. Mam to radsi nez C#.

[Člověk z Horní Dolní]

Mam to radsi nez C#.

Proč?

[vlastikroot]

Protoze delam na linuxu a pro windows jen builduju. Jinak se mi Qt proste libi, ciste subjektivne. Clovek vyuzije featur jazyka dosyta k prospechu svemu.

[lmb]

Haskell, pripadne F# nebo Scala. Mesicni prijem programatora v UK ~ 75k Kc ;)

[chytrák]

Tyhle peníze mají javisti v bankách v Praze. Cobolisti maj víc :)

[lmb]

no jo, ale za daleko vic prace ;)

[MrLaurence]

jenom? bych nak cekal vic. a to nemluvim o financnim sektoru...

(bohuzel, nemluvim z vlastni zkusenosti )

[xxar3s]

http://www.nicollcurtin.com/jobs/7193/F-developer--architect--engineer--Investment-Banking/

[chytrák]

Já bych šel do Javy. Ne kvůli jazyku, ale kvůli JVM. Přece jenom čím dál víc jazyků běhá na JVM, takže znalost platformy není k zahození. Jinak je to ale celkem jedno co se budeš učit. Ty jazyky si jsou natolik podobné, že zbývající 2, co neumíš, zvládneš za chvíli taky. U C++ je hlavní nevýhoda to, že když se naučíš jednu knihovnu (třeba QT), tak o ostatních toho stejně moc nevíš a musíš začít skoro od začátku. Tohle se ti kvůli rozsáhlosti standardní knihovny u javy nebo .netu nestane.

[Martin Beránek]

Naučit se jazyk je otázka týdne. Naučit se v tom jazyku myslet a naučit se knihovny trvá roky. A i pokud budu umět celou "standardní knihovnu javy" (tohle sem fakt ještě nikdy neslyšel) - tak běžně se pro vývoj používá řada dalších frameworků (perzistence, web, ioc, ...).

Java je dnes moc velká platforma a ani zkušený programátor v PHP se během prvního roku nedostane na jinou než juniorskou úroveň... (IMHO). Začít se učit Javu je běh na dlouho trať a otázka několika let v případě že s tím má člověk denní zkušenost. Nechci odrazovat, ale je třeba si to dobře promyslet

[chytrák]

Spíš jsem myslel to, že základní věci jako IO, kolekce atd. jsou společné snad ve všech programech (a to by měl junior určitě ovládat). Kdežto v C++ i tohle má STL jinak než QT atd. Rozhodně si nemyslím, že programováním po večerech se někdo dostane dál než právě na tu juniorskou úroveň.

[manasekp]

zalezi cemu se chces venovat - weby nebo desktopove aplikace nebo grafika nebo neco jineho atd. Jinak urcite neuskodi naucit se cokoliv

[Josef Kufner]

Pokud chceš mít široký výběr z pracovních nabídek, tak Java a C#. Java je hnus, C# je celkem hezké, ale běhá jen na hnusné platformě. Vyber si.

Pokud se chceš naučit něco zajímavého a rozšířit si obzory, koukni na Lisp, Haskell a Smalltalk. V praxi jsou na nic, ale to co se naučíš se ti bude hodit i v tom PHP a tvůj kód získá na kvalitě i přehlednosti.

Další zajímavá a v praxi používaná technologie je Qt, kde se používá podmnožina C++ rozšířená o signály a sloty. Do samotného/obecného C++ bych se moc nehrnul, to je celkem blivajz (STL obzvlášť), ale pořád lepší než Java.

Co se PHP týče, mám ho rád, nehází klacky pod nohy a dobře se v něm tvoří. Na druhou stranu je v něm kopec nedostatků a historických obskurností. Z profesního hlediska je v něm relativně velká konkurence ze strany mizerných a začínajících programátorů, kteří stahují cenu až nepříjemně nízko a zasviňují Internet hloupostma, ale přitom nepředstavují reálnou hrozbu pro aspoň trochu schopného programátora.

[kovariadam]

Java iste nie je dokonalá, ale hnus? Čo to ako je hnus? Ťažko tomu uveriť od človeka čo má rád PHP.

[Sten]

C++ STL není blivajz, je to akorát hodně komplexní, proto se to běžně vyučuje stylem „takhle to funguje a nikdy nebudete potřebovat vědět proč“. Ale když se šablonové (meta)programování naučíte, přijde vám třeba dost podivné, proč Qt má MOC, když to všechno jde bez větších problémů udělat právě šablonami — což jsem si vyzkoušel třeba tak, že jsem napsal šablonovaný C++ wrapper pro JNI, kde se třídy v Javě mapují přímo na třídy v C++

[Josef Kufner]

Nikde netvrdím, že šablony nejsou mocná věc, ani že STL je nějak nelogické nebo nepoužitelné. Ale když se podíváš na cokoliv netriviálního, tak to je prostě nečitelný bordel.

[Miloslav Ponkrác]

A Vy se z toho co jste popsal musíte něco učit? Vždyť všechno co jste popsal je to samé a na jedno brdo. Jestli se naučíte jedno, zbylé technologie se naučíte do několika dní.

Výjimkou je C++, které je složitější.

Odpovězte si na otázku, proč se chcete učit něco nového. Odpověď co je pak jednoduchá.

Chcete se učit něco, co je jednoduché? – Nejjednodušší je Python, pak C#, pak Java, pak dlouho nic, a pak C++.

Chcete se učit něco, co Vás bude bavit? – Pak je to o Vašich osobních preferencích.

Chcete se učit něco, co Vás bude dobře živit? – Pak to záleží na lokalitě, kde chcete pracovat.

Chcete něco, o co je zájem u zaměstnavatelů? – Pak záleží na Vašem odhadu budoucnosti.

Jinak programovací jazyk je nepodstatný. Dnešní jazyky jsou naprosto primitivní, a klidně se nový naučíte za den. Zvláště, pokud jsou tak vykuchané na dřeň jako třeba Java, Python nebo C#.

To podstatné je jinde. Programovací jazyk je malinká součást celého sw systému. Velmi snadno naučitelná. Jiné dovednosti se získávají hůře a déle.

[rajcze]

Dnešní jazyky jsou naprosto primitivní, a klidně se nový naučíte za den. Zvláště, pokud jsou tak vykuchané na dřeň jako třeba Java, Python nebo C#.

Rad se podivam, jak se za den naucite byt jen Python a jeho standardni knihovnu ;)

[pasmen]

V podstatě jsem chtěl napsat něco podobného. Programovací jazyk je jen nástroj, jehož používání se člověk naučí relativně velmi snadno. Důležité je znát obecné principy, souvislosti a mít rozhled. Pak jde všechno celkem snadno.

[GeoRW]

Javistov nikdy nie je dost, resp. juniori by sa aj nasli ale seniorov je ako hladat ihlu v kope sena

[Мiriam]

To je problém dneška, starší lidé jdou radši do předčasného důchodu a při něm nepracují, takže sehnat seniora na trhu práce je jako hledat jehlu v kupce sena.

[MrLaurence]

Jestli chces jazyk na zamestnani, vez, ze trh s Java programatory je velmi likvidni a berou hodne.

Jestli ale chces, aby jsi roztl i ty, ne jen tvuj plat, zkus Haskell nebo Rust.

• Haskell je vysoce abstraktni a mocna zalezitost. Presto je ale velmi prakticky orientovany 1, 2. Je to jakoby jazyk z budoucnosti za par desitek let. Na druhou stranu musim rict, ze jsou lide, kteri s Haskellem dovadi kouzla, ktera fakt nechapu. Jestli se citis jako cestovatel casem nebo kouzelnik, jdi do nej.
• Jestli se citis vic jako hodinar, zkus Rust. Ma spoustu chytrych napadu z Haskellu. A rust sedi primo na zeleze. (Podezrivam je, ze jmeno nezvolili nahodou.)

[Radek Miček]

Rust je zatím dost nestabilní.

[MrLaurence]

a navic strasne hnusnej. chapete, ze oni se inspirujou Haskellem, a stejne tam naserou stredniky, chlupaty zavorky a ja nevim co... ale nemuzu si pomoct, vidim tam velkej potencial.

[dad]

to jsou velmi zajimave navrhy. Protoze se v tom moc nevyznam, tak bych potreboval nakopnout, kde se pro Haskell a Rust nachazi takove ty repozitare s moduly treba pro fastcgi nebo vytvareni nativnich excel dokumentu. Nebo nejaka pdf-lib, xml-parsery a proste vsechno mozne, co clovek potrebuje ke kazdodeni praci?

[Radek Miček]

Pro Haskell je to Hackage.

[dad]

dik.

Trochu jsem to prosel a oproti tem zabehnutym jazykum je to jeste v zacatcich. Takze uvidime, myslim si totiz, ze to je dost zasadni vec. Trochu vyhoda muze byt, ze je vpodstate mozno si to u tech zabehnutych jazyku okouknout, takze narust tech knihoven muze byt rychlejsi nez tomu bylo drive. A taky se uz dnes vi, co je potreba.

[Radek Miček]

Cituji z rozhovoru s hlavním autorem Haskellu, Simonem Peytonem Jonesem, rozhovor je z roku 2009:

Redaktor: Tell me about Haskell’s unofficial slogan: avoid success at all costs. What’s the origin of it?

SPJ: I mentioned this at a talk I gave about Haskell a few years back and it’s become quite widely quoted. When a language becomes too well known, or too widely used and too successful - certainly being adopted by Microsoft means such a thing - suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things. Success is great, but it comes at a price.

I’m primarily a programming language researcher, so the fact that Haskell has up to now been used for just university types has been ideal. Now it’s used a lot in industry but typically by people who are generally flexible, and they are a generally a self selected rather bright group. What that means is that we could change the language and they wouldn’t complain. Now, however, they’re starting to complain if their libraries don’t work, which means that we’re beginning to get caught in the trap of being too successful.

[lmb]

Trochu jsem to prosel a oproti tem zabehnutym jazykum je to jeste v zacatcich.

To je ale hodně troufalé tvrzení, po zběžném "projití" Hackage.

Pro moji práci, a to jsem dělal na hodně odlišných projektech, mi dostupné knihovny až na výjimky pokryly všechny potřeby. Pokud můžu srovnat s Pythonem, tak je toho jen o "něco" méně. Zavádějící může být i číslování verzí. Tady verze menší než 1.0 neznamená, že to je neodladěná prealfa, ale většinou je to spolehlivý a plně funkční kód. Dtto platí i pro flag Stability.

[MrLaurence]

co vim, tak Rust zatim nic jako Hackage nema. Ale doufam, ze az neco takoveho mit budou, pojmenujou to JunkYard.

[Radek Miček]

Vím jedině o cargo central.

[Člověk z Horní Dolní]

Haskell je mocny, ale pro bezny problemy neproduktivni...

[Ivorne]

To zní jako hrozný stereotyp. "Programovací jazyk XYZ se moc nepoužívá ergo je pro běžné problémy nepoužitelný.". Já bych mu dal šanci. Poslední dobou začíná docela vzbuzovat mojí pozornost.

[Člověk z Horní Dolní]

Neni to kvuli tomu ze se moc nepouziva, ale napriklad proto zena hodne problemu je uzitecnejsi divat se imperativne nez funkcionalne. Nrazil jsem ale i na dalsi veci kdyz jsem si s tim hral...

[MrLaurence]

hodne problemu je uzitecnejsi divat se imperativne nez funkcionalne

jo, to asi jo. Haskell proto pouziva monady a do notatci. imperativni programovani vystavene na funkcionalnich, chcete-li matematickych, zakladech.

problematicke budou spis space-leaky -- line vyhodnocovani. a mozna taky obcas komplikovane zpravy prekladace.

[Radek Miček]

Co to jsou běžné problémy?

[JS]

Vidis, tebe jsem hledal.. Ta Curry-Howard korespondence zni zajimave, ale proc to neobratit?

Co takhle nejdriv napsat ten program, spustit ho na nejakych datech, z toho urcit jake jsou v nem vlastne datove typy a na zaklade toho poskytnout (mozna i jen aproximativni) dukaz korektnosti algoritmu? Nebylo by to pro nektere problemy jednodussi?

K tvoji otazce. Je to asi jako rozdil mezi pristupem matematika a fyzika. Matematik aplikuje abstraktni teorii na realny problem. Fyzik naopak indukuje abstraktni model na zaklade realnych dat ziskanych z experimentu.

[Radek Miček]

Co takhle nejdriv napsat ten program, spustit ho na nejakych datech, z toho urcit jake jsou v nem vlastne datove typy a na zaklade toho poskytnout (mozna i jen aproximativni) dukaz korektnosti algoritmu?

Dokazované vlastnosti by byly někde předem specifikovány nebo by se měly automaticky odvodit na základě výstupu programu?

[JS]

Ten program by se nechal odladit na testovacich datech, takze bychom meli podezreni, ze funguje korektne.

[Radek Miček]

Co mi ale dělá starosti je, odkud se vezmou ty relevantní vlastnosti, jenž definují korektnost. Bude tam standardní knihovna vlastností a bude se zkoušet, které z těch standardních vlastností platí?

Například, když budu uvažovat třídění seznamu hodnot, tak bych chtěl dostat typ, který říká: vstupem funkce je seznam hodnot, které lze vzájemně porovnávat, a výstupem je utříděný seznam hodnot, jenž je permutací vstupního seznamu.

Jak se ubráním třeba tomu, abych nedostal příliš konkrétní typ: např. typ, jenž vyjmenovává konkrétní dvojice indexů prvků v seznamu, které musí jít porovnávat.

Další potíž je v tom, že nějaká vlastnost může platit na mnoha vstupech, ale ne na všech – pak mohu odvodit nesmysl. Příkladem je Fermatův test prvočíselnosti.

[JS]

Neubranis. Pujde o iterativni proces. Dostanes nejaky dukaz, a v nem ty typy zkontrolujes. Na zaklade te kontroly bud dodas dalsi testy nebo upravis ten originalni program tak, aby jsi dostal lepsi priblizeni toho, co chces.

[Člověk z Horní Dolní]

Co jsem napriklad nedavno resil - spoustet / ukoncovat instance Amazon EC2, zadavat jim ulohy, a az dostanu vysledek tak zazipovat a ulozit na disk. Cili hodne I/O. V Pythonu to jde krasne jednoduse. Prijde mi, ze v Haskellu se musi vic premyslet...

Dalsi typicky priklad je optimalizovani kusu kodu - v Jave mam celkem dobrou predstavu, co se deje na nizsi urovni, takze to jde vetsinou zoptimalizovat tak, ze to neni o moc pomalejsi nez C.

[Radek Miček]

Dalsi typicky priklad je optimalizovani kusu kodu - v Jave mam celkem dobrou predstavu, co se deje na nizsi urovni, takze to jde vetsinou zoptimalizovat tak, ze to neni o moc pomalejsi nez C.

Máte pravdu, to je IMO hlavní nevýhoda Haskellu. Nicméně kompilátory Haskellu se stále zlepšují a s určitou podporou v knihovnách se třeba také přiblíží C: Haskell Beats C Using Generalized Stream Fusion nebo What’s in a parser? Attoparsec rewired (2/2)

Cili hodne I/O. V Pythonu to jde krasne jednoduse. Prijde mi, ze v Haskellu se musi vic premyslet...

V Haskellu by to mělo jít podobně jednoduše – myslím, že stačí znát základy na úrovni Learn You a Haskell for Great Good!.

[Josef Kufner]

Hm, pochybuju, že by se Haskell někdy opravdu chytil a začal se masově používat. Co jsem si tak všimnul, obvykle tyhle "zajímavé" jazyky zůstanou na okraji a mainstreamové jazyky časem přejmou některé jejich vlastnosti. Například anonymní funkce v C++ a PHP.

[luky]

Anonymni funkce byly v lispu, ktery se v dobe sve nejvetsi slavy dal povazovat za mainstream. Taky jsou v perlu, kterej byl mainstream na konci minuleho stoleti. Takze anonymni funkce jsou vlastne main stream a nikdo se po nich do obskurnich jazyku nemusel koukat

[vlastik]

Divím se, že tady nikdo nedoporučuje Go... být tazatelem, vážně bych ho zvažoval.

[xxxxxxxxxxx]

Já tomu teda moc nerozumím, ale přijde mně že je tato otázka dosti debilní. Jako by se ptal strojař jaký další CAD by se mněl naučit??? Nejdřív musíš bejt kvalitní strojař a člověk schopnej vymejšlet věci. CAD je až na druhém místě každej dement se ho naučí rychle... Ale přijde mě to jako dosti častej problem porgramátorů, zabejvat se nepodstatnostma a výsledek práce nikde... )

[Člověk z Horní Dolní]

Aha, takze nejdriv musis byt kvalitni programator a az pak ma smysl ucit se programovaci jazyk :D

[xxxxxxxxxxx]

Protože jsi polodementní opice, tak nechápeš že nejduležitější je to co jsi v životě už udělal a jaký projekty máš za sebou a ne to jestli umíš 10 jazyků voe...

[pasmen]

A proto se říká Kolik jazyků umíš, tolikrát jsi člověkem, co? Kromě toho, asi budeš mít trochu problém s chápáním kauzality. Na tvojí obhajobu, u lidí jako jsi ty je to celkem běžné

[Dát smazat]

Tyhle "nepodstatnosti" jsou to, na co se ptají (a testují) u pohovorů a jedna z věcí, které rozhodují o přijetí a úspěšném přečkání zkušební doby.

Samozřejmě že jsou i jiné věci důležité - přístup k práci, přístup k lidem, ochota se učit, logické a soustředěné myšlení...

Ty náznaky urážek ignoruju.

[xxxxxxxxxxx]

Na junior pozici asi ano. Já jsem šel vždicky cestou práce že jsem měl za zády nějak projekty a prošel jsem téměř vždicky.

[Ivorne]

Ono dělat projekty bez znalosti nějakého programovacího jazyka taky nebude žádná pohodička.

[xxxxxxxxxxx]

Jo to samozřejmě, souhlas. Jenom jsem narážel na ten fakt že se probíraj programovací jazyky jako by znalost množství byla upřednostněna nad tím co je s nimi člověk schopen vytvořit.

[chytrák]

Jenže strojař je limitovaný fyzikálníma zákonama a ten CAD mu jenom nahrazuje papír. Programátor je limitovaný maximálně rychlostí počítače a ten programovací jazyk je vytvořený na základě nějakého vymyšleného matematického modelu. A ty modely se tak liší, že když znáš jeden, tak to pro učení druhého vůbec nemusí být výhoda. A když to vezmu čistě pragmaticky, tak proč by se programátoři zbytečně dřeli, když lidem stačí, že se zabývají nepodstatnýma detailama a ještě je královsky platí.

[xxxxxxxxxxx]

Víš proč je platí? Protože idioti jako já tomu nerozumí. ))

[Kvakor]

Programátor je limitovaný maximálně rychlostí počítače a ten programovací jazyk je vytvořený na základě nějakého vymyšleného matematického modelu. A ty modely se tak liší, že když znáš jeden, tak to pro učení druhého vůbec nemusí být výhoda.

V programovacích jazycich se spíš říká paradigma než model, ale jinak je to přesně tak - programátor, který se "naučí myslet" v jednom paradigmatu může mít problém s jinými druhy paradigmat (je to vlastně slabé verze Sapir-Whorfovy hypotézy aplikované pro programovací jazyky).

Například někdo, kdo začínal s nízkoúrovňovými jazyky bude mít problém s různými vysokoúrovňovými abstrakcemi a tudíž je (ke své škodě) nebude používat, pokud to nebude nutné (aneb "Opravdoví programátoři dokážou psát ve Fortranu v jakémkoliv jazyce" ), naopak ten, kdo začínal v jazyce s vysokou mírou abstrakce bude mít problém v okamžíku, kdy je postaven před relativně nízkoúrovňový problém, na který chybí předem připravené řešení (a jako důsledek pak páchá pomalé a paměťově nenasytné obludky).

Naprotitomu u podobných druhú jazyků bude přechod mnohem jednodušší a hlavním problém bude, jak už tu bylo několikrát napsáno, naučit se znát knihovny a rozličné frameworky, což může trvat roky.

[Grunt]

programátor, který se "naučí myslet" v jednom paradigmatu může mít problém s jinými druhy paradigmat

To by mělo být vytesáno v nějakém kameni. OOP se mi do hlavy vtloukat snažili, ale já vůl prostě ne a ne pochopit k čemu takový krám sloužit může.

[Gilhad]

No, ja OOP zacal chapat, az kdyz jsem si prosel v (dis)assembleru co a jak to dela. (uznavam, sverazna cesta, ale u me vedla k cili zrovna tahle).

Docela sikovne to je napriklad, kdyz mas spoustu dat, ktere maji castecne podobnou strukturu a castecne se lisi a potrebujes s nima delat masove operace, ktere jsou podobne, ale drobne se lisi podle typu dat. Kdyz ta data das do objektu a misto abys "je predhazoval funkcim" tak "volas jejich metody" tak se prekladac sam postara, aby se kazdy typ tech dat zpracoval spravnym zpusobem.

Napriklad mam pisnicky, reklamy a hlaseni, ktere je potreba nejak nacist, seradit a prehrat. Kazde se nacita z jine tabulky, reklamy maji pri prehravani jeste znelky pred sebou a za sebou, kdyz je vypisuju do logu, tak u pisnicek me zajimaji i alba, u reklam nikoli a u hlaseni me nezajima ani autor. Playlist, ktery v prubehu prace sestavim a okolo ktereho se to toci obsahuje pestrou smes vsech techto typu.

Takze bud budu mit vsude mraky slozitych ifu, nebo u kazdeho zaznamu odkaz na tabulku funkci, ktere s nim pracujou a nebo to necham na kompilatoru a pouziju to jako objekty. Kdyz se to dobre udela, je to o neco prehlednejsi.

[Grunt]

No, ja OOP zacal chapat, az kdyz jsem si prosel v (dis)assembleru co a jak to dela.

Já přesně takhle pochopil Céčko (na ukazatele už jsem potřeboval GDB), takže proč ne? Nápad je to moc dobrý.

[Ondřej Kubečka]

Jazyk je nástroj a volí se na různým místech podle účelu (někdy dobře, někdy špatně). Alespoň u nás máme sklony nenajímat pouze podle aktuálních dovedností. Prostě když někdo přijde, že je machr třeba na Perl, který zrovna nepotřebujeme, tak si ho pořádně proklepneme. Když se potvrdí, že nekecal a zároveň je ochoten se naučit něco dalšího, tak to často stačí, protože lze předpokládat, že i v námi aktuálně používaném jazyce bude schopen dosáhnout potřebné úrovně. V každém případě obecně platná odpověď dle mého neexistuje.

[Karel]

trochu OT.

hele, kvuli tomu CAD, co tady tvorime. Je to takova nahoda, ale kdyz uz delas v tom Ulmu 50 metru od Daimleru, tak bys tam snad mohl zajit a trochu se pozeptat Juergena Riegela, co dela na tom FreeCADu, jake jsou dalsi plany. Ze by se to trochu s Vladou Zimou zkoordinovalo. Treba Vlada neco zainvestuje, aby se to hnulo trochu dopredu. Nebo aby Juergen minimalne prozradil, proc vsadil na to OpenCascade.

[Dát smazat]

Koukám, že se to rozjelo docela jinak než jsem doufal...

[radix]

Java

Ma jistou budoucnost, je hodne prace, je lepe placena, je mene zprasena nez PHP, je lepe podporovana nez PHP ...

Alternativy: - C++ - dost prace, ale lowlevel, v rukou sileneho programatora je to velmi, velmi nebezpecny jazyk - C# - je to dobry (lepsi jazyk nez Java), ale vyhledove jen pro Windows (Mono muze MS kdykoliv zatrhnout), vysoka zavislost na jedne firme (nejen co jazyka a platformy, ale i do knihoven)

[Anonymous]

Zajímavou možností by mohlo být Ruby (třeba spolu s Ruby on Rails). Ne tak často jako PHP, ale také se využívá.

A samozřejmě zvyšováním kvalifikace v PHP a přidružených technologiích se také nic pokazit nedá ;)

[Michal Karas]

Ruby je fajn jazyk, ale IMHO se uplatňuje víceméně jen pro webařinu. Takový Python (jako hlavní konkurent) se používá i pro systémové programování a GUI aplikace.

Zajímavý je Elixir, který běží nad VM Erlangu a míchá do toho syntax právě z Ruby - stojí za tím člověk z rails-core. Spousta lidí z Ruby komunity v tom vidí budoucnost. Na hype křivce bych ho osobně zařadil někde k již výše zmíněnému Rustu.

[MrLaurence]

Python... pro systémové programování

ne, ne

Elixir

hmm, zajmave...

[Michal Karas]

OK OK, měl jsem na mysli programování systémových nástrojů.

[multi]

Prijde me divne tady na foru vubec uvazovat o C#.

Java je dobra, ale nevim jak se ji povede od te doby co ji ma pod kridly Oracle...

Osobne z toho co jsi vyjmenoval jsem pro Python.

[Bystroushaak]

Osobne z toho co jsi vyjmenoval jsem pro Python.

+1

[Petr Tomášek]

Já bych se naučil nějaký přirozený jazyk. Počítačové jazyky jsou nudné a hnusné

[mirec]

Haskell