ARCHIV

Ahoj, chtěl bych se zeptat jaké programovací jazyky jsou určeny pro webové aplikace a které pro pc, případně jaké pro obě možnosti?

Ve web aplikacich se na klientske casti (www prohlizec) pouziva JavaScript, pripadne Java, Flash, Air, Silverlight nebo JavaFX. Na serverovou cast se pouziva v podstate cokoliv v cem umi ten kdo to dela programovat - Java, PHP, python, groovy, perl, ASP.NET,
...

Univerzalnim jazykem je treba Java, ktera umi ve spolupraci s GWT knihovnou bezet jak na serveru, tak prelozena do JS na klientu. I kdyz java umi bezet v prohlizeci i primo.

Děkuji za odpověd a ještě bych chtěl vědet jestli je pravda, že na programování je nejtežší algoritmus? A jestli když se pochopí(a naučí) jeden programovací jazyk tak ty další už jsou poměrně lehké?

Vetsina programu je velmi jednoducha, zadnou specialni vedu tim myslim algoritmus v nich nehledejte. Programovani je hlavne o praxi a nauceni se knihoven.

Pro zacatek bych zkusil neco udelat v Groovy = http://groovy.codehaus.org/Download .
Je to scriptovaci dynamicky jazyk, takze se vyporada prakticky s cimkoliv co mu zacatecnik predhodi beztoho aby produkoval nadmerne mnozstvi chyb pri kompilaci a je lepsi nez Python. Stahnete si spring ide = http://www.springsource.com/landing/best-development-tool-enterprise-java a muzete si zacit s groovy hrat. Pokud ale chcete vytvaret neco grafickeho a animovaneho tak to bych si vzal JavaFX - je to taky scriptovaci jazyk a animace se v nem delaji velmi snado. Zalezi co za typ aplikaci chcete vyvijet, ale obadva mnou doporucovane jazyky bezi na Java platformne takze maji pristup ke vsem knihovnam ktere pro javu existuji, takze se naucite i ty knihovny.

rozhodne bych zacatecnikum nedporucoval JavaScript, C, C++, pascal. V tech se dost snadno udela v programech chyba.

Ten Groovy možná zkusim............A ty knihovny znamenají co?

„V tech se dost snadno udela v programech chyba.“

Což je velmi dobré pro začátečníka, aby dělal chyby. Protože profesionálem se stane jen ten, kdo se s určitými chybami vypořádával.

Navíc mám pocit, že předřečník je Java závislák a svět mimo Javy moc nezná.

Třeba zrovna Pascal je typicky učební jazyk. Jako začátečníka Vás naučí mnohem více, než si dokážete představit - naučí Vás základní disciplíně, vysvětlí základní pojmy a rozhodně Vás do připravení k programátorskému řemeslu připravíá výrazně lépe a dá Vám lepší základ, než jakákoli Java, a potažmo Groovy.

Pascal ovšem není moc vhodný pro běžné používání, ale jako učitel je to vynikající jazyk.

A ještě jeden postřeh: Neznám a za celou více, než 20ti letou kariéru jsem nepoznal žádného dobrého programátora, který by se naučil dobře programovat na Javě, či cokoli Java derived. Naučil se to na jiném jazyce.

Pro začátečníka je Java matoucí. Mate pojmy, a dělá začátečníkovi bordel. Namísto pravých pojmů je v Javě hodně věcí emulated by class.

JavaScript jako první jazyk skutečně vhodný není. C/C++ naopak výborně, pokud chcete dělat low level věci.

Ale Pascal je pro začátek vynikající volba, ovšem nesmíte u Pascalu zůstat.

Pokdu ovšem chcete dělat výhradně web, jděte jinou cestou.

Viděl bych to spíš na ten web, aspoň pro začátek. Tam byste mi doporučil jaký jazyk?

Pascal je k nicemu. Zadna z modernich programovacich praktik se v nem neda moc dobre realizovat. Vzdyt umi jen funkce, procedury a uzivatelem definovane typy. Zadne objekty, rozhrani, zadna dedicnost.
Proc by se nekdo nenaucil dobre programovat na Jave? Ze primitivni typy nejsou objekty? V C++ taky ne. A programovaci jazyky pro JVM (JRuby, Jython, ...) nejsou Java derived, pouzivaji jen stejnou platformu pro vykonavani kodu a maji tak pristup k Java knihovnam.
Vam sice vadi Java, ale nabizite jako alternativu pascal, ktery neumi zdaleka ani to co umi Java.

Navic Groovy neni Java a v Groovy je vsechno objekt. Groovy je moderni jazyk, ktery umi spoustu pokrocilych veci.
1. staticke typovani
2. dynamicke typovani
3. closures
4. regexp na urovni jazyka
5. metaclass programing
6. multimethods
7. operator overloading
8. GroovyBeans
9. scripty - kod se nemusi uzavirat do class
10. range operator
11. anotace
12. natahovani knihoven z maven2 repozitaru

Groovy je idealni pro zacatecnika, muze si v nem vyzkouset libovolne programovaci techniky a nic ho neomezuje. C++ je spatne navrzeny jazyk, proto ho taky Java dneska uz bezproblemu vytlacila - lepe se v ni dela. C to je jina vec, ale rozhodne neni pro zacatecniky vhodna diky pointerum. C bych se dneska neucil pokud nechcete delat nizkourovnove veci.

Groovy ma v zakladni knihovne jak servlety, tak sql, tak sablony takze se da delat web i v nem bez pouziti Grailsu. Navic kdyz mate pristup k java knihovnam tak klidne muzete pouzit i jine sablonovaci systemy ci pripadne jina rozhrani k databazi - hibernate, jdbctemplate apod.

Tady jde o to, co to jsou ty "moderni programovaci praktiky". Pokrivene OOP na styl javy? Takovety veci, jako ze public/private/protected je jedine opravdove OOP, ze single-dispatch je opravdove OOP, ze tridy a jejich konstruktory jsou neco kouzelneho...

K tomu C: ja si popravde receno myslim, ze zacit od C a pointeru (a nejake konkretni predstavy, jak ten abstraktni random-access stroj funguje) je velmi dobry napad. Naopak souhlasim s tim, ze pascal neni to ono, kdyz jsem se ucil programovat ja, tak me dlouho od C odrazovalo to, ze zatimco v Pascalu se da na nejake odsazovani vcelku uspesne kaslat a stejne je to citelne, tak v C to nejde.

Ale to co jsi tu popsal znamená výhodu pro Pascal :)

Ale asi vím o čem mluvíš - když jsem ještě učil programování, tak jsem za boha nedokázal vysvětlit některým lidem odsazovaní - to co generovali bylo úžasný. Na to je super Python, i když uznávám, že je to diskutabilní funkce, ale v Pythonu se téměř každý naučí odstazovat správně :)

V Pascalu se ale poměrně dobře vysvětlují základní datové struktury - strom, vázaný seznam, .. V C ten samý kód je úspornější, ale už je tam příliš hvězdiček za sebou

Me osobne vzdycky prisla logika pointeru v Pascalu takova lehce pomatena a poradne (na neco jineho nez banalni spojaky) jsem je zacal pouzivat az pote, co jsem toho napsal docela dost v C a assmbleru, fakt je ze to mozna je hlavne tehdejsi Borlandi snahou ty pointery co mozna nejvic schovat a tvarit se, ze to jsou prece proste "objekty". Popravde recno, mechanizmus spravy pameti v Delphi/VCL jsem poradne nepochopil dodnes (a rekl bych ze je to tim, ze normalni programator nema nejmensi potrebu do neceho takoveho stourat).

S tím jsem vůbec problémy neměl - ale možná to bylo tím, že jsem začínal ještě s 5.5 - a nikdy jsem Borlandí objekty zvlášť nepoužíval. Co se mi ovšem na Pascalu líbí je jasná formulace předávání parametrů hodnotou nebo odkazem. Což je první zádrhel pro začínající programátory - hned druhý je zanořený cyklus :). OOP bych v Turbo Pascalu asi nezkoušel. To už je hodně pasé - navíc OOP v TP je takový zvláštní mix - designováno pro Mac, vyrostlo v Dosu (TurboVision) a nakonec se ještě dost upravovalo pro win.

No me treba cely koncept predavani parametru odkazem prijde ponekud zcestny.

„Děkuji za odpověd a ještě bych chtěl vědet jestli je pravda, že na programování je nejtežší algoritmus?“

Podle toho co děláte. Jestli běžnou pásovou výrobu, která je dnes zaměřena na to, abyste nemohl nic zkazit a pouze v zásadě lepíte polotovary /hotové knihovny) k sobě - pak je to rutina.

A pak jsou situace, kdy algoritmus je klíčový.

„A jestli když se pochopí(a naučí) jeden programovací jazyk tak ty další už jsou poměrně lehké?“

Programovací jazyk je nástroj, v zásadě jsou všechny jazyky na jedno brdo plus mínus.

Takže když bych začal webem - treba PHP a potom(až se to naučim-za hodně dlouho) přešel na pc aplikace - třeba C/C++ tak to nebude takový problém?

Pokud zacnete s PHP tak ho s nejvetsi pravdepodobnosti uz nikdy neopustite. Umi a dela v tom kazdy student, coz znamena velka konkurence na trhu prace, male platy a navic je v nem neefektivni (tedy pomaly) vyvoj z cehoz vyplyva ze plat musi byt zakonite mensi nez u efektivnejsich technologii (kuprikladu Springs).
PHP je jednoduche na nauceni, protoze v podstate nic poradneho neumi a ma zpraseny navrh jazyka, coz se lidem libi protoze se nemusi nic ucit. Protoze nic neumi tak je v tom neefektivni vyvoj protoze vsechno tam musite resit rucne a navic je zname nekompatibilitou jednotlivych verzi.
Musite pochopit ze ten kdo spatne seje tak take spatne sklizi. Pro dosazeni lepsich zisku je potreba investovat do vzdelani. Javisti maji zhruba dvojnasobny plat oproti PHP lidem.

To jsou argumenty :) - pak bych doporučoval začít s COBOLEM, REX nebo PL1. Těch pár lidí, kteří umí v těchto jazycích programovat jsou nechutně přepláceni :). V podstatě platí - čím horší prostředí, tím lepší plat - poněvadž minimum lidí je ochotno v tom dělat. Nejsem si ovšem jistý jestli to platí o pro výuku. Pokud začnete něčím složitým jako je JavaEE, tak dost možná pohoříte. Navíc zákonitě z Vás nemusí být dobrý programátor - možná dobrý kóder, ale ti rozhodně nejsou přepláceni - naopak je to spotřební zboží - s horšími podmínkami než mají PHPkáři. Navíc to, co platí dnes nemusí platit za dva tři roky - střední školy, fast univerzity generují hromadu rychlokvašných kodérů v Javě. Pokud se nezmění trend, tak budete muset být dost dobrý abyste se v Javě prosadil.

Pro to, aby se člověk stal programátorem potřebujete znát základy řemesla - což má dnes minimum programátorů, musíte se dobře naučit prostředí se kterým pracujete a hlavně nesmíte minimálně pár let ustrnout v jednom prostředí. Všechno to chce pár let a pár dobrých učitelů, kteří vysvětlí a pomohou. Alespoň já nevím o žádné skvělé platformě, která by o tolik převyšovala nějakou jinou - ačkoliv Java je opravdu dobrý Jazyk, JavaEE je neskutečně velký a komplexní bazmek, kterému rozumí minimum lidí, a je navržený pro "lepiče". Setkal jsem se s tím, že Javisti vůbec nedokázali implementovat jednoduchý algoritmus - i jednoduché věci řešili nesmírně složitě - v podstatě vůbec netušili, co a jak která část systému dělá - což je daň za komplexnost.

Osobně bych doporučil následující postup:

1) Pascal - pro naučení základních datových struktur a postupů (rekurze, lineární seznam, strom, hledání půlením intervalu, bublesort, quicksort, input, output, ukazatele). Přeci jen v Pascalu jsou ukazatele podány jednodušší formou. Případně pokud nechcete Pascal, tak doporučuji Modulu

2) Je dobré znát základy C - tak aby člověk pochopil základy systémů - správa paměti, správa procesů, správa vláken, low level přístup k souborovému systému, Člověk by měl pochopit co je to ukazatel na ukazatel, co je to backcall, co je to hook, atd

3. Hodí se přečíst si něco o Lispu - minimálně pro zvládnutí lambda výrazů (kalkulu)

4. Jednodenní kurz SQL - LEFT, RIGHT JOIN, agregace

A po zvládnutí výše uvedeného můžete začít s PHP, PHP frameworky, Javou, JDBC, C#, .NETem.

Rozhodně nedoporučuji začínat s čímkoliv z prostředí Javy, .NETu, Tato prostředí jsou natolik komplexní, že jim do hloubky skorem nikdo nerozumí - a jejich naučení trvá několik let - což po zvládnutí základů nevadí - na to máte celý život. Jinak výběr jazyka, knihovny, prostředí - IDE - je v 99% subjektivní - prostě hledejte, učte se, až najdete to, co Vám vyhovuje, co ladí s Vaší filozofií, z čeho máte radost. To, co vyhovuje jednomu nemusí vyhovovat druhému. To, co dnes jede nemusí být tak populární za 2-3 roky. Např. Java tu asi bude stále, nicméně obliba jednotlivých prostředí, knihoven se mění každé 2-3 roky.

Ja bych doporucoval ucit se obracenou metodou - to jest shora dolu.

lineární seznam, strom, hledání půlením intervalu, bublesort, quicksort - to dnes nikdo nepotrebuje, od toho jsou knihovny co tohle zaridi. V komercnim vyvoji musite udelat rychle (cti levne) vysledek a nevynalezat jiz objevene. C je k nicemu pokud nechcete delat nizkourovnove veci jako system a knihovny.

Java neni komplexni. Jako jazyk je jednoducha, urcite lehci nez C/C++. Nektere knihovny z J2EE slozite jsou, ale nektere vubec ne, navic v J2EE 5 se to vyrazne zjednodusilo.

Kuprikladu ORM mapery jsou lehke na pouziti, staci dodat anotace do tridy.

@Entity
class neco {
@Basic
String a
@Id
@Generated
int id
@Version
int version
}

a muzete ji hned ukladat do databaze. Je to velmi snadne. Ignorujte implementacni detaily (JDBC a SQL) pokud je nepotrebujete. Misto makefile pro C se naucite Maven2, jsou na to ide kde si to muzete cele naklikat.

Ohledne tech platu zadejte si do googlu: PHP programator plat a Java programator plat.

Tak tady zatínám pěsti :). Tohle je přesně to, co se dělat nemá. Souhlasím s tím, že Java má na všechno knihovny - qsort je i v libc. Jenomže musíte vědět proč tu či onu funkci použít. Tohle je klasický šlendrián - rychle vydělat peníze bez ohledu na výsledek - bez ohledu na to ci o tom myslím, tak tak to nejde dělat dlouhodobě - mizerných javistů jsou mraky - Indové budou vždy levnější - a jejich cena bude jenom klesat. Zas na druhou stranu - čím mizernější budou noví programátoři - tím víc práce a víc peněz bude pro starou gardu - nicméně nechtěl bych být Váš žák - ale platí, že žák si vybírá učitele.

Jenomze pouziti knihoven nedela vysledny produkt horsi, ale lepsi. Podivejte se na to jak lidi koduji v PHP. Delaji nasledujici chyby: neosetrovani chybovych stavu - vubec nekontroluji vracene hodnoty fci, nepouzivani transakci, SQL Injection, XSS. Tohle dela naprosta vetsina PHP programatoru. Ze je to spatne je nezajima, protoze to "neco" dela a chybove stavy nejsou ochotni resit.
Tohle vsechno nenastane pokud pouzijete nejaky z Java frameworku, ktery to vsechno ohlida za vas. Budete muset napsat mene kodu a dostanete navic lepsi vysledek. Tomu ja nerikam slendrianstvi, ale efektivni prace.
Indama mne nestraste, vsechny firmy co outscorovali IT do indie dost ztratily na kvalite. Vemte si treba IBM, tam hned poznate podle kvality ktery produkt delaji prevazne indove. Indove jsou levni, ale nekvalitni a nemaji motivaci delat kvalitni praci. Dneska indie uz moc neleti. Vim jak indove pracuji, delal jsem s nima. Cinani pracuji rozhodne lepe nez indove.

Abychom si rozuměli - vůbec nic nemám proti knihovnám - ani proti Javě, jen prostě nesdílím Vaše nadšení pro Javu hlavně coby prostředí s kterým by měl programátor začít. Je docela smutné, když programátor nemá tušení o hash tabulkách, bublesortu nebo qsortu. To je to co tu kritizuji. Souhlasím s Vámi, že je hodně špatných PHP programátorů - ale dodám, že je zrovna tak dost špatných programátorů v Javě - akorát, že dělají jiné chyby - nicméně provoz trochu komplexnějších aplikací v Javě je také chuťovka - problémy s pamětí, neuvolňováním spojení do db atd atd. Já jsem opravoval aplikaci v PHP, kterou jsem znalostí algoritmu hledáním půlením intervalu zrychlil 1000x. Mám známého, který přepisuje aplikace v Javě po kodérech a zrychluje aplikace 10 násobně.

Je přeci úplně jedno jestli použijete PHP, Java nebo .NET framework - musíte vědět jak ho použít - v podstatě neznám framework, který by např. zabraňoval SQL injektáži. Pokud programátor nebude rozumět problému, tak může libovolný fr. ohnout tak, že chybu udělá.

Když chcete být dobrý truhlář musíte rozumět dřevu a nebo být montérem v IKEA - s tím, že nikdo od Vás nic nečeká, maximálně můžete překvapit. Programování je řemeslo, a dobrý programátor musí rozumět základům řemesla.

Hashtabulky java programator zna, ty se bezne pouzivaji. Nevi sice jak funguji uvitr, ale to je implementacni detail ktery ho nemusi zajimat. qsort, bublesort to znat nepotrebuje - tridi totiz budto databaze nebo standardni knihovna.
Spatny programator v Jave nikdy nevyprodukuje takovy spatny kod jako bezny programator v PHP. Protoze: 1. transakce mu dela AS nebo framework, 2. chyby mu osetruji vyjimky 3. SQL injection zabranuji Criteria Select API z JPA ci PQL. 4. Ano nezavirani spojeni do DB to byva problem, ale vetsina AS uz umi detekovat spojeni co programator zapomnel zavrit a vracet je nazpet do poolu.
Javista udela vzdy lepsi vysledek nez PHPista protoze i kdyz o dane technologii nic nevi tak to za nej udela framework. Kdyz treba nevic nic o transakcich ale pouziva spring services, tak kazdy servis je transakcni default. To same v EJB.
Jinak treba pureQuery od IBM zabranuje na 100% SQL injection, staci vzit libovolnout JDBC/JPA aplikaci a v pureQuery zamknout pristupovy plan, zadne jine SQL dotazy to pak uz do db nepusti.
Vy tvrdite ze spatny Javista udela stejny vysledek jako spatny PHPista, coz neudela. Predstava ze Javista je pouhy lepic zatimco PHPista je pan programator je naivni. Porovnejte vysledky jejich cinnosti. V PHP se frameworky moc nepouzivaji protoze jsou pomale. V Jave jsou ale rychle a tak se tam muzou pouzivat bezne bez podstatneho vlivu na vykon.
Naprosta vetsina lidi co delaji v PHP jsou spatni programatori. Kdyby byli dobri tak by nikdy nedelali veci rucne kdyz to za ne muze udelat framework. Kuprikladu: chcete psat JavaScript rucne nebo ho generovat z GWT? Zkuste delat jeden tyden oboji a pak si porovnejte efektivitu prace.

Nikdy jsem neřekl, že Javisti jsou lepiči a PHPkáři páni programátoři. Nicméně v obojím lze bastlit, v obojím se bastlí. Rozhodně Java není spasitelná. Navíc si myslím, že jste dost zaspal dobu - poslední 3 roky frameworky intenzivně používají i v PHPku, prozíravější PHP programátoři je používají už 5 let - co vím. Osobně si myslím, že špatný Javista napáchá mnohem víc škody než špatná PHPkář - vzhledem k tomu jak a kde se primárně nasazují aplikace psané v Javě. Rozhodně nemůžu se nadchnout pro extra bazmeky typu pureQuery a pod, které z malého problému, který lze snadno řešit, dělají velký - a komplexní. Je to super, za těžké peníze, ale není to nic pro mne. Líbí se mi jiná kultura programování.

Jenomze v Jave se musite vylozene snazit abyste to zprasil, zatimco v PHP to zprasite bez vynalozeni jakekoliv namahy. Jen se podivejte do tech prirucek LAMP co litaji po netu jaky styl prace v nich uci. Mate namysli nejaky konkretni PHP framework? Oni jsou ve srovnani s Java frameworky dost slabe, zatim jsem nevidel zadny ktery by alespon solidne umel ORM.
Bazmeg typu pureQuery je dobry kdyz mate velkou zprasenou aplikaci. Za levny peniz ji muzete zkulturnit a vyrazne zrychlit.

Takže ty bazmeky, kvůli kterým musíte používat pureQuery byly zpraseny záměrně? To mi vyjde, když Vás chytnu za slovo a spojím Vaši první a poslední větu. :). Je otázkou, co chcete od frameworku. Já od nich rozhodně neočekávám ORM - žádné ORM neumí SQL tak jako já. Osobně si myslím, že je nesmyslné porovnávat Javu a PHP. Od každého očekávám něco jiného a každé přináší něco jiného. Je to totéž, jako kdybych kvůli existenci C zavrhl Bash. Myslím si, že pro účely, kde se nasazuje PHP, jsou stávající frameworky dostačující - třeba Nette, Symfony a další.

Jinak s Vámi mohu souhlasit s bídnou úrovní LAMP dokumentace - potažmo aktivní nápovědy na různých fórech. Myslím si, že se situace lepší - ale internet by potřeboval radikální jarní úklid - a nejen internet. Bohužel internet je veřejné fórum, a sebelepší rozumný nápad, technické řešení vyprovokuje alespoň jednoho oportunistu, který bude prohlašovat, že je to špatně, na nic a k ničemu, a že postaru je to dobře. V 90 letech se ještě dalo s takovými lidmi diskutovat, a většinou si stáli za svým. Po komercializaci internetu ale došlo k záměrným marketingovým útokům - takže až na výjimky řada zdrojů - nejen o PHP je nevěrohodná, nepoužitelná. Internet napřed znamenal absolutní boom ohledně dostupnosti informací - jenomže v druhé vlně pak tím, že informace jsou tak laciné a tak dostupné vede k tomu, že se nevyplatí udržovat a pořizovat kvalitní informace - což vede k úpadku kvality :(

Ale ne, pokud pouzivate ORM tak se pureQuery pouziva jen proto aby udelalo z dynamickeho SQL staticke SQL, protoze staticke SQL je rychlejsi. Nejlepsi pouziti pureQuery je aby odprasilo aplikaci ktera pouziva JDBC, coz je prave ten styl prace ktery vy doporucujete - psat SQL dotazy rucne. To je u vetsich aplikaci nevhodne, protoze kdyz pak zmenite datovy model tak musite prepsat vsechny SQL dotazy, kterych bude pozehnane a navic muzete delat v SQL dotazech posilanych serveru preklepy. Proto je lepsi nechat SQL dotazy generovat pomoci ORM.
Nevim proc bychom nemohli porovnavat technologie na vyrobu web stranek - javu, php, rails, django. Cil je prece udelat web stranku.

Nakonec jsem se rozhodl začít s Pythonem a dál uvidim.

No python neni zase tak spatna volba (php i ruby jsou horsi), ackoliv pouzivani mezer jako syntaxe neni zrovna dobry napad.
Mne se na pythonu nelibi: mezery jsou soucasti syntaxe, mrseni namespaces pri importech, dynamicke typovani, globalni promenne, nedusledna kontrola chyb pri prekladu do .pyc, mrseni zpetne kompatibility, mizerne drivery pro databaze.
Jeden cas jsem mel python rad, ale na vetsi veci se mi neosvedcil. Dneska bych ho uz nepouzil, Groovy ma spoustu python-like rysu a navic ma closures a volitelne staticke typovani.

Co je spatneho na globalnich promennych? Ze zmizi duvod pouzivat x ruznych "design patternu", ktere jsou jenom na to aby se obesel fakt, ze Java/.NET nic takoveho nema?

Globalni promenne to je mor a rozhodne to nepatri mezi spravne techniky strukturovaneho programovani. Predavat parametry pres globalni promenne neni moc ciste, co kdyz budeme chtit udelat z kodu modul ktery pak muze mit vice instanci.
zejmena v PHP aplikacich je to mor, tam muzou jeste nastat pripady zda je promenna tohoto jmena vubec definovana, protoze aplikace obvykle includuje podle potreby nekolik desitek dalsich php souboru z nichz nektery promennou nadefinuje a nejaky dalsi jiz pocita s tim ze mu ji nekdo nadefinoval, pokud ho ovsem nenaincludujete v dalsi vetvi programu drive nez ten co to promenou definuje a nastavi.
PHP ten jazyk se hlavne nemel nikdy tak masove rozsirit, lidi v nem neskutecne prasi a to tak dokonale ze IDE prostredi ktera automaticky parsuji kod aby umeli napovedu jsou z vetsiny PHP vytvoru mimo. Pravda na Python kodu se taky moc nechytaji tam se taky da prasit (kuprikladu importy v if).
Kdyz ale vezmete Groovy a Spring IDE tak to IDE se krasne chyta a rozumi tomu kodu. S tim je pak radost pracovat.

Ja netvrdim, ze globalni promenne je nejak dobry napad casto pouzivat. Ja tvrdim, ze to ze programovaci jazyk podporuje globalni promenne rozhodne neni jeho nevyhoda.

Je. Kdyz date do ruky programatorovi prostredek na praseni tak si budte jist ze on prasit bude.

Ja si myslim, ze by mela velmi zahy vymrit tahleta teze, ze LISP je nejak jako o lambda-kalkulu a nejakych silenych teoretickych zakladech.

Jednak: neni neco jako "LISP", ale spousta ruznych jazyku, ktere se sobe podobaji casto jenom syntaxi a nejakou ramcove obdobnou sadou primitivnich typu.

A hlavne: pokud si vezmeme temer libovolny z nich, tak z nejakych velkych funkcionalnich teorii je tam zhruba tak stejne jako v temer libovolnem "skriptovacim" jazyku, nebo treba C# a to: funkce jako objekt a zanorene lexikalni rozsahy platnosti promennych. Vicemene neexistuje prakticky pouzivany derivat LISPu, jehoz semantika by lambda kalkulu nejak rozumne odpovidala (ony totiz ty produkcni pravidla prestanou fungovat, pokud clovek pripusti side-efekty a modifikovatelnou pamet). To co si clovek z toho, ze pricichne k nejakemu LISPu je neco uplne jineho a to ta neuveritelna flexibilita toho, ze si muzete vymyslet vlastni konstrukce, ktere vypadaji uplne stejne jako bezne ridici struktury samotneho jazyka (+ takove knihovny, ktere uz nekdo napsal).

Jinak konkretne Common Lisp ma tu vlastnost, ze je to historicky prvni standardizovany OO jazyk, pricemz pristup k OO v CL je v mnoha ohledech naprosto opacny, nez vyse zminene "moderni programovaci praktiky" a je jiste velmi zajimave se podivat, jake tim vznikaji naprosto netusene moznosti. A takle by se dalo pokracovat dlouho. Zaver tedy je, ze alespon zbezne se podivat na nejaky LISP (treba Cl, nebo treba dfsch, chtelo by to dalsi vyvojare ;)) je velmi prinosne, ovsem je potreba se oprostit od toho, ze je to spustitelny lambda kalkul. Dalsi podobne zajimavy jazyk je treba Smalltalk. Pricemz oba tyhle jazyky maji (stejne jako Ada a tusim SQL/PSM) uzasnou vlastnost: system osetreni neocekavanych situaci, ktery dava narozdil od vyjimek smysl.

Pavle díky za větu: „Navíc zákonitě z Vás nemusí být dobrý programátor - možná dobrý kóder, ale ti rozhodně nejsou přepláceni - naopak je to spotřební zboží - s horšími podmínkami než mají PHPkáři.“ Velmi pěkně jsi trefil problém Kóder vs. programátor, který většině začátečníků naprosto uniká.

Proč bych měl u php navždy zůstat?
Plat zatim řešit nemusim....na to mam ještě spoustu času. Za těch pár let bude všechno jinak.

To je takovy poznatek z praxe. PHP je velice uzce zamereny programovaci jazyk (napriklad se v nem neda rozumne naprogramovat vetsina takovych vylozene "zacatecnickych" programu bez pomerne hlubokych znalosti). Vetsina programatoru v PHP pak ziska pomerne zvlastni pohled na to jak to cele funguje a nasledkem toho se velmi tezko uci jakykoliv jiny programovaci jazyk. Nebo alespon tak mi to prijde, programatoru co zacli a zkoncili na PHP jsem potkal relativne dost.

Mírně nesouhlasím. Ano PHP lepičů, kteří jsou levní je hafo, těch co jazyku opravdu rozumí a chápou matematiku (pořád mě nikdo nepřesvědčil, že programování není aplikovaná matematika) i algoritmizaci, je docela málo. Z těch co znám jsme nikdo nezačínali na PHP, ale třeba v 80. letech s BASICem, Assemblerem (jojo, ještě bych možná dal dohromady nějaké fragmenty na Z80), nebo později Pascal a C. Dá se říct, že jazyk je pro nás jen prostředek vyjádření, který volíme podle dostupnosti a není velký problém přejít poměrně rychle na jiný (opravdu se bavím jen o jazyku, nepočítám znalost frameworku, knihoven, …).

PHP není tak zprasené, jak to vypadá podle zdrojáků začínajících vývojářů. To že se potkávají zprasené kódy je dané tím, že se lze velmi rychle dostat k napsání prvních scriptů a ty prostě nějak fungují. O tom jak fungují se nepřu, protože občas vidím sílená zvěrstva od lidí, kteří nepochopili rozumnou práci s databází, nebo se snaží nacpat objekty do kódu za každou cenu.

Srovnání platů je mimo, kvalitní PHPkař je placen stejně dobře jako kvalitní Javista. Pravdou je, že průměrný Javista je placen lépe, než lehce nadprůměrný PHPkař. A pokud jede člověk jako OSVČ, tak coby PHPkař snadněji najde zákazníka, protože dostupnost hostingu.

Jsou pro i proti. Osobně bych dneska začal Pythonem, nebo Scheme (bohužel dnes už jsem natolik zafixován na klasické postupy, že Scheme nejsem štonc pochopit, to už je úplná změna myšlení), pokud pochopí algoritmizaci, je změna jazyka vcelku triviální.