Vlákno názorů k článku
Jmenné prostory a další novinky v PHP 5.3

Bohužel se začíná ukazovat nedostatečná odbornost vývojářů jazyka. Postupně z toho dělají opravdu šílený bastl. Ještě že už jsem z toho kolotoče pryč!

A ostatním doporučuji v rámci udržování znalostního portfolia zkusit alespoň python nebo ruby.

Ten jazyk je vážně hnus. Trochu se mi dělá šoufl ze zpětných lomítek, ale to je jen detail.

Neříkám že v tom bastlu nejde napsat dobrá aplikace. Ale Python a Ruby, to je prostě krása.

Nejsilnější stránkou PHP jsou hostingy, to je bez debat.

Chápu to samozřejmě jako nahrávku na flame :-).

Zpětných lomítek jsem se také děsil, ale dá se na to zvyknout velmi rychle a ve jmenných prostorech to vypadá nakonec docela přirozeně, subjektivně lépe než čtyřtečka.

Já jsem v Pythonu rok dělal a zas tak krásný mi ten jazyk nepřijde. Např. absence skutečně privátních proměnných je podle mě jasná chyba návrhu jazyka, některé věci se zase dělají podle mě zbytečně krkolomně.

A na Ruby se mi zase nelíbí, že dovoluje přepisovat metody.

V čem je (skutečný) problém absence privátních proměnných? Problém s public proměnýma je, pokud vím, ten, že po klientech třídy rozprskneš přímý přístup do paměti objektu – takže objekt nemá možnost reagovat. Pokud ale existuje možnost „obalení“ do properties, tak tento argument padá. To v pythonu (i v php) jde.

Co se týká kontejnerů, to je věc názoru, mě se míchání obyčejného a asociativního pole v php osobně nelíbí a nezdá se mi to o tolik složitější (ani pro začátečníky, spíš naopak).

Ty deskriptory jsou možná trochu složitější, ale jde to udělat i jinak

Jinak na pythonu oproti php oceňuji mimo jiné menší „psychologickou“ náročnost. Například nedávno jsem napsal něco takovýho: …array_map(arra­y(‚Sql‘, ‚q‘), $items)… 

Jinak pravda, právě s 5.3 několik silných argumentů v neprospěch php padá. Což je dobře. a říkal jsem si, kolik wtf bude, až to bude někdo číst. A pak jsem to pro zajímavost zkusil v pythonu:
map(Sql.q, items) Je to v podstatě stejné, ale když čtu něco podobného jako v té php variantě, tak mě to napřed vyleká (ok, jsem zbabělec). Podobně je to s tím, když se používá jen . (tečka) versus :: \ → (což je teda opačný případ k tomu array() versus [] {})

Jinak, uznávám, právě s php 5.3 několik silných argumentů v neprospěch php padá. Což je dobře.

A jé to tlačítko zobrazit náhled funguje :(

Věta

Jinak pravda, právě s 5.3 několik silných argumentů v neprospěch php padá. Což je dobře.

se mi omylem dostala i doprostřed příspěvku (srovnání map a array_map)

„Např. absence skutečně privátních proměnných je podle mě jasná chyba návrhu jazyka“

Huuu? Co to jsou privátní proměnné? Lokální proměnné funkcí? K těm je přístup jen uvnitř jejich scopu. Já bnýt programátor v PHP, tak se soudy o „jasných chybách návrhu jiných jazyků“ značně šetřím. Mnohé z nich byly skutečně navržené. Python má sice nedostatky, ale ty jsou aspoň soustavně opravovány.

„A na Ruby se mi zase nelíbí, že dovoluje přepisovat metody.“

No tak v tom případě musíme Common Lisp, Scheme (R5RS), Smalltalk a asi dva tucty dalších jazyků zahodit do koše jako ouplně nepoužitelné.

Víte, co by Vám na to řekli autoři jazyka Lua? „If you don't want to do something, just don't do it.“

Co se privátních proměnných týče, tak jako vývojář knihovny nechci, aby mi k ní uživatelé přistupovali jinak než přes veřejné API. Samozřejmě, že když se tím nebudou řídit, tak to bude jejich chyba, ale vysvětlujte jim to pořád dokola.

A co se přepisu metod týče, tak to naráží v situaci, kdy se dvě knihovny rozhodnou přepsat stejnou metodu a já chci použít obě. Třeba Rails by se dalo těžko použít s jinou knihovnou, která by přepisovala stejné metody.

Mantra „If you don't want to do something, just don't do it.“ se bohužel dá použít jen v situaci, kdy všichni vývojáři hrají na stejné straně. Při vývoji knihoven to je ale tak, že musím respektovat ostatní knihovny a někdy bojovat s uživateli.

Ok, uznávám, že na tvých argumentech něco je.

Pokud potřebuješ privátní proměnné chránit před útočnými nájezdy hloupých kolegů, tak chápu, že by se ti opravdu privátní proměnné líbily. Já v praxi nic takového nepotřebuji, protože moji kolegové prostě umí v Pythonu programovat. Kdyby programovat neuměli, nepomůže nic.

Třídy ze standardní pythoní knihovny s touto vlastností taky žijí. A rozhodně se s nimi pracuje líp než s tím nekonzistentním hnojem co má v základu PHP.

Velká výhoda Pythonu je v tom, že umožňuje odložit řízení přístupu k datům „na potom“. V Javě když uděláš proměnnou public, tak už ji nikdy nebudeš kontrolovat (leda by jsi změnil rozhraní). Proto jsou javovské programy plné nicnedělajících a zbytečných getterů-setterů. V Pythonu můžeš veřejnou proměnnou vždycky obalit a mít ji pod kontrolou.

PHP má v možnostech řízení přístupu stejnou výhodu. K původně veřejné vlastnosti si kdykoliv později mohu dodělat getter a setter, přičemž zvenku se s ní pracuje pořád stejně. Pokud v tom má člověk systém (např. ten, že metody pojmenovává getWidth a setWidth), tak se to dá navíc zautomatizovat.

Takze nakonec to dopada tak, ze vsechny vlastnosti tridy jsou private a nad to se posadi globalni __get a __set, ktery vsechny ty „prekrasny“ private elegantne zrusi :) Hlavne ze se to tvari „zapouzdrene“. Ale to neni jen o slove private, protected a public, to je o spravnem navrhu trid. A zpetne lomitko to „programatory“ v php nenauci.

Co se mi ale libi, jsou inline funkce, ze by konecne nabeh na pouzitelnou lambda fci?

V tom případě by byly stejně out i set/get přístupové metody – nesprávný návrh tříd?

Python má pseudoprivátní proměnné, kterými říkáte, že by se neměly používat. Ale obcházet encapsulation prase dokáže např. i v C++: #define private public ;)

Doufam, ze to brzo skonci. Ukazuje to spise nevuli hostingu. Napr. google se svym appengine ukazal, ze to jde.

Vyvoj napr. v Jave se mi zda s pouzitim dobreho frameworku minimalne zabavnejsi. O efektivite a prehlednosti nemluve…

Na PHP (a stejně tak i Ruby nebo Pythonu) je vidět nedostatečná odbornost vývojářů v oboru „návrh počítačového jazyka“. To je bez debat.

Ale co s tím? Přestat tyto jazyky používat? Přestat programovat? Nebo uspořádat finanční sbírku a zaplatit si Anderse Hejlsberga, aby pro LAMP navrhl lepší jazyk, třeba vycházející z nějakého výše uvedeného? Asi by to bylo nejlepší, ale je to utopie.

Muzete rozberat tu nedostatecnou odbornost vyvojaru Ruby nebo Pythonu? Co si pod tim clovek ma predstavit?

Nic, David Grudl zase dělá chytrého. Toho si nevšímejte.

Ruby má jednu veľkú nevýhodu David o tom písal aj v tomto článku:

http://latrine.dgx.cz/…ekuji-nechci

No to rozhodne zadna nevyhoda neni :) Doporucuji nastudovat Smalltalk.

A Common Lisp. A nestatické implementace Scheme. A dva tucty dalších jazyků… :]

Python je krásný jazyk, má jen takový drobný problém, že autor si mění syntaxi a nutí přepisovat programy.

V PHP nikdy tak tvrdá změna v syntaxi jazyka, jako v Pythonu nenastala. Je naprosto jedno, jaký je Python jazyk, když zpětná kompatibilita je pro pythonisty sprosté slovo a snaží se to prakticky dokázat.

Ruby je na tom stejně, ale s tím, že řada věcí je tam dosti všelijaká. Například Ruby je snad jediný jazyk, který až do verze 1.9 neměl znakový typ. Autor Ruby nesnáší Unicode. Možnost rozšířit kdykoli definici jakékoli třídy kýmkoli, dokonce i systémové v core jazyka.

Python má stabilní větev 2.x a stabilní větev 3.x. Můžete klidně zůstat na 2.x, která bude udržována i do budoucna, a užívat si backporty těch změn, které nezpůsobí zpětnou nekompatibilitu.

Ruby znakový typ nemá, stejně jako Python. Pouze ve verzi 1.9 přešlo Ruby na tentýž komcept, jaký je v Pythonu, a sice že „znak“ je řetězec délky 1. Autor Ruby není Unicode-hater, ale m17n-lover. Řetězce v Ruby 1.9 podporují m17n.

Možnost rozšířit libovolnou třídu byla převzata ze Smalltalku a (Common) Lispu. Stejně tak si můžete zajít do kuchyně pro nůž a zkusit, co se stane, když si ho probodnete hrudníkem, ale většina lidí to nedělá o nic častěji, než Smalltalkeři předefinovávají ifTrue: a ifFalse: metody (má to samozřejmě pedagogickou hodnotu ;-)). V Common Lispu je tuto fíčuru nutné odemknout, protože balík CL je defaultně zamknutý, ale vývojářům se tím usnadňuje a urychluje vývoj samotné platformy – můžou měnit a ladit kód standardních knihoven a ihned ho zkoušet s „ostrými daty“ bez větších prodlev.

Jak jsem poznamenal výše, vývojáři jazyka Lua k podobným tzv. „nedostatkům“ poznamenali: „If you don't want to do it, just don't do it.“

Nic, Miloslav Ponkrác zase dělá chytrého. Toho si nevšímejte.

(Sorry, ale to byla tak krásná nahrávka – prostě jsem neodolal.)

Vyčítat Pythonu stabilitu při srovnání s PHP je fakt důmyslné. PHP rozbíjelo aplikace i při desetinkových (nebo i setinkových?) updatech. Zatímco Python má po X letech nekompatibilní, jasně definované pokračování s nástroji a návody pro přechod.

Rozdíl je ten, že v Pythonu to je záměr a v PHP chyba :-).

a to jste jeste nevideli jak vypada vykonna cast Zend Engine. Je totiz z goto kompletne sestavena.