Python vs Ruby - co se učit pro vývoj webových aplikací rubrika: Programování: Jiné

4 hutlik007
položil/-a 2.11.2014

Už delší dobu přemýšlím nad webovou aplikací (šlo by o sociální síť - profily, zprávy, stavy, ...). Nebyl by problém ji napsat v PHP, ale kód psaný procedurálně bude po delší době vývoje nepřehledný a OOP se mi v PHP moc nelíbí (takže ani nemám chuť se učit nějaký framework pro PHP nebo se víc přiučit a napsat vlastní), proto přemýšlím, že se naučím jiný programovací jazyk.

Přede mnou teď stojí volba, který jazyk se učit, případně kterým začít. Proto se chci zeptat, který jazyk je podle vás lepší - Python s Djangem nebo Ruby s RoR - z hlediska rychlosti učení a vývoje? Jaké s těmito jazyky máte zkušenosti? A kde získám nejlepší podklady pro učení? Díky moc za všechny tipy a rady

Komentáře

  • jiri.knesl : a jaké aplikace budeš programovat? kdo to bude platit? jak velké týmy? každá technologie má své klady a zápory. 3.11.2014
  • mnohosten : Podle me premyslis spatne. Jestli programujes v PHP a jeste sis necichnul k nejakemu frameworku, tak neni reseni jit se naucit nejaky jiny programovaci jazyk a ucit se jiny framework v nem. Jestli umis PHP, tak se jej nauc poradne. Programovat proceduralne v PHP muze byt sice zajimave z vykonostniho pohledu, ale je to trochu mimo mainstream. Snadno tak porusis KISS, DRY apod. IMHO OOP je v PHP jednoduse navrzene, pro pochopeni je to mnohem jednodussi nez treba v C++. 7.11.2014
odkaz
9 Taco
odpověděl/-a 2.11.2014

PHP
Rozšířenější, větší podpora hostingů, větší komunita.
Volitelná statická typovost, jinak slabě typovaný(plus mínus), třídní OOP, magické metody. Bližší Javě a spol.
Výborná podpora balíčkování v podobě composeru.
Nemá moduly, jen třídy v globálním prostoru jmen. Jinak obsahuje dobře implementovanou většinu obvyklých programátorských nástrojů. Dokonce i traity.

Python
Slušná komunita, slušná podpora, číslo jedna ve skriptovacích jazycích na desktopu (bash nepočítám).
Opravdu čistý návrh jazyka, i když někdy dost po svém. Objektové OOP, dynamické silně typovaný. Duck-typing místo interface. Magické metody. Anotace. Metaprogramování. Výborně zpracované moduly v duchu OOP.
Je řádově rychlejší než PHP.
Balíčkování pomocí pip, ale mě to furt zlobí.
Pro mě, jako příznivce statického typování, to je dost nepohodlný jazyk. Zvláště duck-typing mě nehorázně štve. Ale je dost mocný, a na desktopu a na prototypování je skvělý.

Ruby
Zde nemám osobní zkušenost, jazyk mě nezaujal, takže píšu jen co jsem slyšel.
Prototypové OOP a s tím spojený Monkey-patching. Prý se dá do určité míry ohnout za účelem DSL.
Slabá podpora hostingů (o žádném nevím).
Z těchto tří nejpomalejší.

Pokud se ti nelíbí OOP v PHP, tak se nejdříve zamysli nad důvodem. Není OOP, jako OOP.

Komentáře

  • kohven : Přijde mi trochu zavádějící to: "globálním prostoru jmen"? Neznalý člověk by z toho mohl usoudit, že PHP nepodporuje namespaces. Což samozřejmě podporuje. Akorát to nemá něco jako *.dll nebo *.jar (nebo o tom alespoň nevím). 4.11.2014
  • Taco : Možná. Ale je to přesné. A bohužel i s důsledky, které to přináší. Když si zmínil *.jar (které s namespaces natož s moduly nijak nesouvisí) umí Java načíst dvě třídy s různou implementací ale stejným jménem (včetně namespace)? Takže například budu mět balíčky foo1.jar a foo2.jar a v nich budu mět stejně pojmenovanou třídu org.example.foo.Foo ? (nechce se mi to zkoušet) 4.11.2014
  • vaclav.sir : Něco jako jar by mohl být phar. :-) 5.11.2014
  • Taco : V jednom příspěvku mět třídy, moduly, namespace a balíčky - kruci, to nemůže dopadnout dobře. 5.11.2014
  • JaSei : Ahoj, me se to tvrzeni, ze je ruby z tech tri nejpomalejsi nelibi... Jednak staci otevrit google a zjistis ze si najdes banchmark, ktery potvrdi, ze tvuj preferovany scriptovaci jazyk _je_ nejrychlejsi (napr. http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-python-php-a... - ruby je nejrychlejsi, python je nejrychlejsi zas treba http://opennomad.com/content/performance-different-scripting-languages-s... - uznavam, uz jen to ze datum zverejneni tech clanku je dost rozdilny neco znamena;))... Ale je fakt, za na YAPC v Kyjeve chvalili ruby, ze hodne zapracovali na performance, takze bych ho nepodcenoval - mam pocit ze v tuhle chvili zaostava v performanci spis perl... Nicmene podle me srovnavat rychlost scriptovacich jazyku je nesmysl, protoze kdo chce delat hi-performance aplikace stejne po scriptovacim jazyku nesahne;) 5.11.2014
  • Kit : Skriptovací jazyky jsou rychlé, když se používají tím správným způsobem. Ani ten Perl v performanci nezaostává... 5.11.2014
  • Martinex : Řešit předražené české hostingy bez funkcí, když svět řeší cloud? Co třeba Heroku? Stejně, když dnes neděláte "one-click deploy", tak je někde něco špatně. 5.11.2014
  • David Adamczyk : Martinex: pokud delaji petistrankovou webovku pro Frantu automechanika z nejake dediny pak skutecne nepotrebuji ani Heroku ani DigitalOcean a ani Python nebo Ruby :) 5.11.2014
  • kohven : @Taco: Nevím a zkoušet se mi to taky nechce. Ještě jsem neměl tu potřebu. Jinak já znám pojem "globální prostor jmen" asi z jiných jazyků nebo kontextů, takže v tom trochu tápu. Chtěl jsi vyjádřit to, že něco není identifikováno jenom názvem a namespacem, ale i názvem modulu? Byl by případně příklad nějakého jazyka, kde je to "lepší" a není to jen v globálním prostoru jmen? Cítím, že v tomto mám mezery. 5.11.2014
  • Taco : @kohven: U většiny třídně objektových jazyků (PHP, ale typuju i Javu, ač bych jí nerad křivdil), když nadefinuješ třídu, tak se ti zaregistruje globálně pro všechny. (Namespace to neřeší, jen přidává delší jméno.) Což má důsledky, že bez nějaké extra magie nemůžeš použít dvě stejně pojmenované třídy (do názvu započítávám i ns). Také to obvykle má vedlejší důsledek neexistenci modulů (představ si něco jako instance třídy, kterou předáváš protože obsahuje statické metody odpovídající rozhraní). Naopak, objektové, nebo i prototypové jazyky s tím nemají problém. V Pythonu si prostě modul, nebo třídu nahraješ do proměnné, a děláš instanci z instance modulu, nebo třídy. A protože to je dynamická instance, je s ní mnohem větší legrace. 5.11.2014
  • Kit : @Taco: V PHP jsou přece všechny instance dynamické. Ty snad používáš statické metody? Mohu používat různé třídy se stejným názvem třídy i ve stejném namespace. Záleží jen na schopnostech mého autoloaderu. 5.11.2014
  • skliblatik : @Kit tak to by mě opravdu zajímalo jak. Stačí když ukážeš jak v 1 běhu použiješ dvě "různé třídy se stejným názvem třídy". 5.11.2014
  • Kit : @skliblatik: Můžeš přece použít aliasy. Takže pro tvoji aplikaci ty třídy mají různé názvy. 5.11.2014
  • Taco : @Kit: Základní problém je v tom, že v php třída není instance, tudíž ji nelze předávat jak parametr. 5.11.2014
  • vaclav.sir : Nemůžeš, dostaneš "Fatal error: Cannot redeclare class". Tohle se dá dělat v Pythonu, že importuješ do proměnné, ale v PHP ne. 5.11.2014
  • Taco : @Kit: Modul je balík funkcí, které odpovídají nějakému rozhraní, a já je proti tomu rozhraní můžu předávat. Nejblíž je tomu zneužít klasickou třídu, a v ní nepoužívat this. Což je funkční, ale akademikovi ve mě se to nelíbí, protože je tam to this a není to singleton. 5.11.2014
  • skliblatik : @Kit aha takže nevíš v čem je problém... Není problém v use, problém je v include. Každá třída má nějaký název. Řekněme, že máš kód "...class Tool{..." Pokud tuto třídu nezařadíš pod namespace, tak je její globalni název \Tool. Pokud ji zařadíš pod namespace (tzn. ten soubor, v němž je třída napsaná začíná "...namespace Kit..."), pak je globální název této třídy \Kit\Tool. Pokud máš soubor lib1/a.php a v něm namespace Kit a třídu Tool a ten inkludneš, tak se do globálního prostoru jmen zavede \Kit\Tool. Pokud máš soubor lib2/a.php a v něm opět namespace Kit a třídu Tool a i ten inkludneš, tak jsi v háji, protože "Fatal error: Cannot redeclare class". 5.11.2014
  • rmaslo : Já si pod pojmem "globální prostor jmen" vždy představovat to, že když nadefinuji třeba funkci uvnitř jiné funkce tak tato funkce není vidět zvenčí té první funkce. V PHP bohužel vidět je. U funkcí jde v PHP toto nevhodné chování obejít pomocí anonymních funkcí uložených do proměnných. Ale nic takového jako $x = class {...}; $obj = new $x() v PHP nejde, takže podle mě je zde - z hlediska tříd jen jeden "globální prostor jmen" 5.11.2014
  • Taco : @Kit samozřejmě ví, že alias _přidává_ nový název, takže to problém neřeší. Jen dělá ruch. 5.11.2014
  • Taco : @rmaslo: Přesně tak. 5.11.2014
  • Kit : @Taco mě odhalil. Samozřejmě vím, že to nejde. Pokud bych potřeboval zmrazit verzi knihovny se stejným namespace, tak to namespace změním přidáním čísla zmrazené verze. To je trivialita. Naštěstí jsem to dosud nepotřeboval. 5.11.2014
  • Taco : Praktičnost této věci je jiná otázka, a neodvažuji se to odhadovat. Mě se to třeba (v Pythonu) hodně osvědčilo při prototypování, kdy běžně dělám wrapper nad wrapperem nad wrapperem nad několika různými knihovnami a různými verzemi. A pak to stejně přepíšu do Haskellu. 5.11.2014
  • Kit : Haskell bych se také chtěl jednou naučit, ale v tuto chvíli si vystačím s XSLT, který je sice trochu ukecanější, ale vyhovuje mi. 5.11.2014
  • Bystroushaak : @Kit: To byl doufám vtip. 5.11.2014
  • Kit : Ne. Proč by měl být? Chceš snad tvrdit, že XSLT není ukecané? 5.11.2014
  • Bystroushaak : Chci říct, že srovnávat Haskell a XSLT je jako srovnávat osedlanou krávu a hvězdolet. Dát tyhle dvě věci do stejné věty mi přijde asi stejně absurdní, jako tu krávu poplácat po bocích a šeptat jí do ucha "jednou poletíme ke hvězdám Stračeno, zatím mi ale stačí, když mě dovezeš domu". 6.11.2014
  • Kit : Nevím jak ty, ale já bych Haskell s osedlanou krávou nesrovnával a XSLT s hvězdoletem také ne. 6.11.2014
  • Bystroushaak : Jak to, že nevíš jak já, když už jsem to udělal? 7.11.2014
  • michal sv : V cem je Python rychlejsi nez PHP? Mozna v regularnich vyrazech, ale nic moc dalsiho mne nenapada. Mozna pak jeste nejake optimalizovane datove struktury. 7.11.2014
  • Kit : @michal sv: Kolem PHP je spousta FUD. Někdo s ním pracovat umí a někdo ne. 7.11.2014
  • jiri.knesl : michal sv: Python je mnohem rychlejší než PHP, mnohdy je výkonnost Pythonu podobná kompilovaným jazykům, což o PHP bohužel neplatí 8.11.2014
  • Kit : @jiri.knesl: To známe. Existují malé lži, velké lži a benchmarky. PHP ztrácí hodně výkonu v cyklech a při přepisování hodnot v proměnných. Pokud se tomu vyhýbám, výkon PHP za Pythonem nezaostává. 8.11.2014
  • Taco : Škoda, že nemůžu najít ten odkaz na interpret PHP napsaný v Pythonu, který byl několikrát rychlejší než originální php interpret. Bohužel takhle jsem na tom stejně jako vy všichni ostatní. Tvrzení proti tvrzení. 8.11.2014
  • podhy : Taco: myslíš HippyVM? To je skutečně rychlejší. Pouze má jednu vadu na kráse a to, že neobsahuje téměř žádné extensions, takže to není moc pro reálné použití a co o tom vím (nebo jsem slyšel), tak extensions budou hlavně placené. 8.11.2014
  • Taco : @podhy: Ale jako demonstrace rychlosti Pythonu dobré. 8.11.2014
  • Taco : Rychlost je to poslední, co bych u PHP obhajoval. Ale má proti ostatním řešením (Python) několik pro mne zásadních věcí: 1. Rozšířenost, 2. třídní OOP, 3. interface, 4. volitelný type-hinting. Nebýt duck-typingu, který jde přímo proti mému mentálnímu modelu, byl by Python bezkonkurence. 8.11.2014

Pro zobrazení všech 10 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.