Názory k článku
Vývoj PHP 6

Na Unicode jsem zvedav. V Jave je unicode nativne uz od pocatku, na jednu stranu to je vyhoda, na druhou stranu s tim jsou obcas problemy. Jestli tady chtej mit utf-16 ... no uvidime jak se to vyvine, ale tipuju ze tady bude zdroj problemu. A nemoznost nastavit unicode per skript/adresar? To budou zas na hostingu hadky typu chci/nechci unicode ..

No aspon ze konecne zlikviduji ty magic_quotes...

Unicode v php hodnotim ako pruser, ale cesta ktorou sa vydali je jedina pouzitelna na shared a free hostingoch kde admin nieje schopny zbuildovat locales podla poziadavky. imho zatial to vyzera na unicode=off a setlocale rulez!

Kdyby jen zbuildovat locales ...

mne to zatial stacilo vzdy... ine tuzby som nemal. co by tam mohlo este vadit?

No nejvic asi zaple magic_quotes ... a nemoznost nastavit to v .htaccess pro kazdou subdomenu zvlast (pro svy skripty to mam vyply, ale obcas jsou nektery systemy, ktery to chtej zaply ... )
Podobne s register_globals...

Unicode naopak mělo být v PHP dávno. Zejména při práci s XML se chybějící podpora Unicode musí všelijak obcházet.

pruser som myslel implementaciu. Podla benchmarkov sa niektore veci spomalili aj o 300%.

Obchadzat? preco? IMHO, je to skor problem pouzitych kniznic, ktore viedia aj neviedia o kodovani dokumentu...

Takže je teď PHP stejně rychlé jako konkurence ;-)

Ne, vážně, s Unicode a kódováním je v PHP5 pořád spoustu "sraní" (omlouvám se, ale je to nejvýstižnější). Některé problémy viz: http://www.kosek.cz/temp/unicode.pdf

BOM - tazko povedat. strlen() a spol, tam staci spravne nastavit len locales, a jediny jediny problem co vidim je normalizacia retazcov.

No, ještě deset až patnáct let a bude z toho současný Python s Unicode, pojmenovanými parametry i prosotory jmen :-).

Jo, Python bez 2D layoutu, to by mohl byt dobry jazyk ...

Koukam nejsem sam co nema tuhle 'featuru' rad ... python, haskell ... a ani i ty tabulatory vs 8 mezer u Makefile neni to pravy orechovy :O)

S tím se dá docela dobře žít, táké jsem se toho původně obával, ale šlo o liché obavy, stačí dodržovat konvenci, odsazuje se o čtyři mezery. U PHP je nutno se smiřovat s mnohem horšími věcmi.

No ja mam ve zvyku odsazovat o jednu.
A obcas jsou i pripady, kdy je pro prehlednost lepsi pevnou konvenci na nekterem miste programu opustit a naformatovat to trochu jinak.

Napriklad ja si "znackuju" kod nulovym indentem jako "tenhle kus chce prepsat/odstranit". Coz treba v pythonu asi nepujde ....

To se urcite strasne dobre hleda :-)

To dělám taky, většinou to co přijde odstranit, různé debug. výpisy a pod... Hledá se to výborně ;) Ale v pythonu je potřeba přejít na nějaký ten TODO a XXX markup.

Místo vymýšlení nové a úžasně nekompatibilní verze PHP by možná bylo lepší předělat kritický extensions jako IMAP, aby byly thread-safe.

thread-safe, ha nemozne... ZE sa im podarilo ako tak spravit thread safe, ale naco je to dobre ked staci iba jedna libka v dakej ext ktora nebude thread safe a cele to moze ist...

Vytvoření "nového jazyka" s sebou nese jednou nebezpečí - když už budou uživatelé muset předělávat všechny skripty, proč rovnou nepřejít na nějaký úplně jiný jazyk. Možností je čím dál tím víc a některé (lepší) alternativy se dostaly do použitelného stavu.

Bral bych to jako výzvu a šanci opustit PHP jako "jazyk pro lamy" a pustit se do nějakého SKUTEČNÉHO jazyka.

ps. Jakub Vrána se konečně našel. Místo kontroverzních a neumělých pokusů něco naprogramovat (s diskutabilními výsledky) začal psát souhrnné články (viz i minulý o 5.1), které mu viditelně jdou. Sice jsou proloženy jeho subjektivními osobními komentáři se kterými se dá diskutovat, ale jinak pokrývají vše podstatné.

Ale to je prece spravne, ze pri kodovani UTF-16 se pouzivaji znaky s sirkou dva i ctyri byte, viz napriklad http://en.wikipedia.org/wiki/UTF-16 a http://en.wikipedia.org/wiki/Comparison_of_unicode_encodings

Jsem zvedavy, jak to bude PHP zvladat, napriklad Java (resp. knihovny nad ni) s tim ma dost problemy.

Pravda vsak je, ze pouziti UTF-8 by bylo (alespon v nasem jazykovem regionu) pametove vyhodnejsi.

No, ona si totiž spousta lidí plete UTF-16 a UCS-2. Vypadá to, že autor článku mezi ně patří…

Nejenom lidí, ale i aplikací :-( [=klamavá reklama]. Typicky to bývají aplikace psané v C++ (wchary apod.), ale i v Javě, kde se při některých převodech s 32 bity jaksi nepočítá.

Se surrogate pairs (to jsou ty 4bajtové UTF-16 sekvence) by snad problém být neměl, protože PHP bude pro Unicode využívat služby knihovny ICU.

UTF-8 je sice pro určitě texty úspornější, ale je pomalejší na zpracování, protože se musí pracně hledat hranice znaků. UTF-16 je v tomhle přeci jen lepší, protože v mnoha řetězcích se znaky s kódem nad U+FFFF nevyskytují, a lze tak pracovat v režimu 1 znak = 16 bitů. Pouze pokud je v řetězci nějaký znak, který musí být zapsaný jako surrogate pair, přene se na pomalejšé mód, který to umí ošetřit.

Z dlouhodobějšího hlediska bych se nedivil, kdyby jazyky a operační systémy začaly používat pro interní reprezentaci UTF-32/UCS-4. Na zpracování je to nejjednodušší a pamět je levná.

Mnohem zajímavější jsou v Unicode operace jako porovnání řetězců, protože před porovnáním se musí text znormalizovat, aby se eliminovaly alternativní zápisy stejného textu ("á", versus "a" + "akcent čárka nad písmenem").

No pocitat s necim jako "znaky nad 0xffff se nevyskytuji" jaksi v knihovnach nejde ... pak takovy znak prijde a muzem se jit klouzat ... takze s takovymi znaky pak musi pocitat naprosta vetsina funkci pro praci s retezci -> zpomaleni

a utf-32/ucs-4 .... pamet je sice levna, ale ve chvili kdy mam obrovsky kusy textu tak uz muze byt rozdil jestli zaberou 500mb, 1gb nebo 2 gb .... zase pristup "dame uplne vsude ucs-4" asi nepujde ... nehlede na to ze diakritika (nebo jine "podivne" znaky) ve jmenech souboru je prasarna a mela by se vymytit a ne podporovat.

No pocitat s necim jako "znaky nad 0xffff se nevyskytuji" jaksi v knihovnach nejde ... pak takovy znak prijde a muzem se jit klouzat ... takze s takovymi znaky pak musi pocitat naprosta vetsina funkci pro praci s retezci -> zpomaleni Nikde jsem neřekl, že se znaky nad U+FFFF neobsluhují. Jen jsem řekl, že v tom případě se může použít rychlejší implementace řetězcových operací. Prostá a jednoduchá programátorská optimalizace.

No to vaše řešení skutečně moc inteligentní není. Inteligentnější by bylo držet u každého stringu příznak, zda se vejde do BMP, nebo jestli používá surrogate pairs. Něco takového jsem měl na mysli.

TAK levna ta pamet zase neni. Krome toho, stejne tak by jste mohl rict ze je levny vypocetni vykon. Myslim, ze neustala snaha o tom, aby uplne vsechno bylo v tom samem kodovani, je nesmyslna. Stejne programovaci jazyky musi podporovat i binarni stringy (pro praci s binarnimi daty). Holt se k retezci prida krome delky jeste priznak, je-li v 7bit ASCII, UTF-8, UCT-2 nebo UTF-16 a pri spojovani stringu se bude konvertovat ...

Utf8 je pekny bastl, napriklad neexistuje rychly algoritmus pro substring, strreplace a podobne veci. Utf16 bude sice pametove narocnejsi, ale pri string operacich daleko rychlejsi.

Můžete to trochu rozvést? Jaký existuje rychlý algoritmus pro substr z UTF-16, ve kterém může být jeden znak uložen ve 2 nebo 4 bajtech? Napadá mě jedině ukládat si kromě samotného řetězce také tabulku pozic znaků zabírajících 4 bajty (což v PHP pravděpodobně bude), ale totéž by přeci šlo udělat i s UTF-8. str_replace nedělá problém ani v jednom kódování, v UTF-8 naopak bude většinou kvůli menší paměťové náročnosti rychlejší.

str_replace nedela problem? No, porad musim hlidat abych nahodou nenasel zacatek toho retezce k nahrazeni uprostred sekvence bajtu tvoricich jeden znak, takze to bude o neco pomalejsi nez klasicke bytove retezce. U latinky to asi nehrozi ze bych se takhle blbe trefil (i kdyz s retezcem opeprenym diakritikou by to mohlo jit), u cinstiny by uz celkem mohlo.

Připomenu, jak kódování UTF-8 vypadá. Každý znak je buď tvořen jediným bajtem < 128 nebo začíná bajtem >= 192 a pokračuje bajty 128..191. Z toho plyne, že k žádné kolizi dojít nemůže, hlídání, jestli nejsem uprostřed znaku, se děje samo od sebe a v důsledku jde použít normální bajtová operace.

Ale UTF-16 je na tom skoro stejne blbe jako UTF-8, protoze se take musi rozlisovat bytova delka znaku. Jedine reseni je pouziti "dlouhych" znaku na 32 bitu.

Mohli taky pouzit Unicode16 jako java ... sice se tam nevejdou nektery znaky, otazkou ale je ktery vlastne a jak casto je nekdo pouziva. Ale to ani java neresi :O) Ale kdyz uz utf tak tam mohli dat utf-8 ... ma stejny nevyhody jako utf-16 (narocny operace) ale pro jazykyn zalozene na latince zabira znatelne min mista. Jak je to s cinstinou a podobnymi obrazkovymi jakyky tak to uz nevim, ale tipuju ze ve vetsine pouziti bude utf8 uspornejsi.

No, on je to pruser i v Jave, protoze nektere novejsi knihovny plne podporuji UTF-16, coz ale odporuje tomu, ze kazdy znak z retezce je mozne nacist jako (sestnactibitovy) char. Prakticky to moc nevadi, protoze podle http://mindprod.com/jgloss/unicode.html v tech "hornich" castech nic moc duleziteho neni, ale porad se jedna o polovicate reseni, stejne jako tomu je s ASCII+kodovymi strankami pro osmy bit.

UTF-16 je naprosto geniální kódování. Zcela unikátním způsobem totiž sjednocuje většinu nevýhod, které mají jednotlivá unicode kódování: zabírá více místa, je endian dependent, má proměnnou délku znaku… Snad jen skutečnost, že pokrývá celý rozsah Unicode, mu trochu kazí pověst…

Ano, velmi pěkně a výstižně jste shrnul vlastnosti UTF-16 do pouhých tří vět :-) - vytesat do kamene. Jedna z věcí, které mě na celém slavném Unicode vadí, je právě těch několik způsobů kódování, které se ještě dosti pletou mezi sebou (a jak jsem psal o několik odpovědí výše, i tvůrci aplikací si mnohdy nejsou jistí, co vlastně implementují). O prohazování bytů podle platforem (a chybách v knihovnách při zpracování BOM) ani nemluvě.

Pro mě to prozatím pro komunikaci s okolním světem vyhrálo dosti pěkně navržené UTF-8, interně (na úrovni jazyka a knihoven) ovšem bojuji s UTF-16.

No obzvlaste kdyz BOM prileti v pulce stranky, to pak vetsina broweru vychrli par paznaku ... (bohuzel nektere editory to cpou na zacatek kazdeho editovaneho souboru a je jim jedno ze z toho bude include nekde uprostred stranky)

Na svych strankach pouzivam utf-8 (krome tech starych, kde pouzivam to kodovani ve kterem kdysi vznikly), interne pokud mozno taky :o)

Hloupost, Utf16 je to samé co Utf8 a má ty samé potíže, nepleť si to s UCS2.

Ano, jak jsem napsal, UTF-16 má všechny nevýhody UTF-8 (tj. především proměnnou délku znaku) a navíc přidává ještě dvě: zabírá více místa a je endian dependent. Co se vám na tom nezdálo? Nebo jste jen nepochopil ironii?

Omlouvám se, špatně jsem odhadl indentaci a myslel jsem si, že odpovídáte na můj příspěvek.

"Zrušena bude i možnost vyskočit z proměnlivého počtu cyklů divokou konstrukcí break"

Si dělaj kozy, ne? Všude to bude fungovat, jen v PHP ne.

Takže budu hledat v cyklu FOR i = 1 to 1000000 něco, na pozici 3 to najdu, a cyklus poběží až do milionu.
Vážení, while fakt nejde jako náhrada použít vždy!

To zas vymyslel nějakej magor...

ne "break" ale "break $var"

Neviem, ci som to pochopil spravne, ale chystaju sa zrusit iba konstruciu "break $var", konstruckia "break 2" by mala ostať zachovaná. Resp. tam niekde pisu, ze chcu zrusit "dynamic", takze aspon takto to ja chapem.

Přesně tak, vasil to pochopil špatně.

No kdyz jsem to videl tuhle zminku poprvy tak jsem se lek ze chtej zrusit prave break typu "break 2", ale kdyz jsem si to precet poradne, tak jsem se uklidnil :o)

No, ma vubec "break $var" realne pouziti?
Je fakt, ze dycky pujde nahradit necim typu "if ($var==1) break;if ($var==2) break 2;" jen to bude vic psani :o)

možná eval('break '.$var.';'); :-)

Ani jsem netušil, že taková prasárna v PHP šla.

Docela by me zajimal priklad kdy neni mozne FOR prepsat pomoci WHILE.

no je dost mozne, ze hosi zacinali programovat v basicu.

takovy priklad myslim neexistuje.

stejne FOR i WHILE jsou zbytecne - opravdovi muzi to resi rekurzi. ;]

Copak nestačí lispovské GO a LABELS? :-D

a ti jeste opravdovejsi vedi proc tu rekurzi nepouzivaji a pouzivaji cykly :P

a ti jeste chytrejsi vi, ze pouzivaji chytry prekladac, ktery vi, ze rekurze lze optimalizovat pomoci tail-call a tak to i optimalizuji ;]

nebo smyckou typu DO podle stare normy Fortranu. Co na tom, ze je to teoreticky smycka pocitana, my si prece limity muzeme upravit uvnitr smycky :-)))

Čím dál víc sleduji, jak to PHP v poslední době bastlí, tím víc si přeju, abych PHP nemusel už nikdy používat. Vždyť je kolem spousta jazyků, daleko lepších, než hnusně zbastlené PHP. Upřímně řečeno, za 20 let, co programuji jsem se setkal s řadou jazyků, ale PHP bylo bezkonkurenčně to nejhorší, co mě potkalo.

1) na freehostinzích nic jinýho neni
2) je to velmi jednoduše použitelný na "lehký" aplikace, úkoly a databáze, a ještě jednodušejc naučitelný (+ všude jsou tuny příkladů - i když prasáckejch příkladů bez ošetřených vstupů apod. je taky dost, když člověk ví základy a neštuduje z učebnice PHP3, bezpečnostním chybám se vyhne).

ad 1) Bohužel.

ad 2) Jednoduchost PHP je jenom zdánlivá tím spíš, že se až moc mění neustále pod rukama. PHP je ve skutečnosti jen nekonzistentní nalepovák na nalepováku. Osobně si myslím, že existuje mnoho použitelnějších možností na "lehký" aplikace. Několik let jsem intenzívně psal v PHP a teď tvrdě pracuji na tom, abych se s PHP pokud možno už nepotkal. Jistěže není problém PHP zkrotit, ale proč zůstávat u něčeho, co není dobré?

Jdete s php patlanici do rzite, to se neda opravit, jedine zahodit... a prejit na Ruby a Perl a Smalltalk.

mohol by mi nietko podrobnejsie vysvetlit, co znamena utf, ake su rozdiely medzi 8 a 16 apod.... Tomu, kto sa na to podujme vopred dik :)

------------------------------------------
Interviewer: What is your past experience.

Applicant: I wrote PHP for a Web Site

Interviewer: PHP. What the fuck is a PHP. We write programs here. We need programmers. You write scripts. We don't have any jobs for Scripters.

Applicant: Well scripting is like programming, 'cept there's no accounting, no data management, no reporting, but there are a lot of kewl pictures on the web site I scripted, er programmed. Do you have snackies and scooters here?

Interviewer: We need programmers here. Get the fuck out of my office moron.

Applicant: Wanna shoot some pool?

Interviewer: SOMEBODY CALL SECURITY.

Applicant: I no some kewl porn sites.

Interviewer: (As he puts his foot in the applicants ass) GET THE FUCK OUT OF MY OFFICE YOU MORON!
------------------------------------------

... a nejen s phpckarem... ale v ramci objektivity i s patlakem co ma nasprtanou microsofti certifikaci ale neumi programovat. Z vlastni zkusenosti si myslim ze absolventi jinych skol nez MUNI,CVUT, MFF a VUT jsou jako zamestnanci programatori dosti slabi a vytvareji neprehledne a neciste systemy. Algoritmy, prehlednost a programatorkska kultura, to je to o co ve skutecnosti jde.

A v čem tak úžasně sexy děláte u vás? :-D

nezalezi na skole - zalezi na cloveku, na tom jak je ochoten studovat, .... - ja treba na MFF uz nejsem pac me tak trochu vyrazili z analyzy - tak si tu v klidu studuju v olomouci. ale kdyz srovnam svou praci, uhlednost a mysleni a podivam se na nektere "experty" z matfyzu tak si myslim ze jsem na sakra jine urovni nez oni... - ale zpet k tematu :)

nekdo se tu ptal v cem tak sexy piseme kdyz nemame radi PHP - ja osobne radsi v ASP.NET, problem je za na nektere free projekty je problem sehnat server s M$ operacnim system tak to pisu v PHP, ale ma to sakra mezery to psani v PHP

Tak to si ASP.NET ještě užiješ. Já mám téměř vystudovaný UPOL (ještě diplomka :-), vše jsem dělal v Javě. Někdy jsem měl více práce, protože učitelé měli připravené různé komponenty v .NETu a já si to musel přepsat, ale to mi nevadilo. Matalýzu už neučí Mošová, takže by to _mohlo_ být jednodušší, ale tím si projít musíš :-D

Nelíbí se mi ovšem ten příspěvek od Elite. Tenhle "expert" by měl přijít na exkurzi do naší firmy, kde se vyvíjí informační systém v Perlu (mod_perl). To je taky skript, ale ten systém má špičkový návrh i kód. Jazyk nedělá programátora, stejně tak jako škola.

Nechci nějak vyzdvihovat UPOL, ale co se týče teoretických informatických předmětů (numericke metody, paradigmata programování, matematická logika, fuzzy logika a aplikace, neuronové sítě, vyčíslitelnost a složitost, lambda kalkul...) si myslím, že je to škola asi nejlepší. Bere se to poměrně do hloubky. Horší to je s praxí, projekty máme docela snadné.

Myslim ze jste me trosku nepochopil, pokusim se tedy svuj nazor rozvinout. Osobne nic nemam proti skriptovacim jazykum jako takovym (a Perl je samozrejme hodne zajimavy skriptovaci a dynamicky jazyk), ale proti rychlokvasenym "radobyprogramatorum" kteri slyseli ze v programovani "solej prachy kamo" a tak se nauci trosku toho html a nejake to "pehapecko" a jdou na vec. Uplne podobne typy se vyskytuji na jine strane barikady kde zase "delaji do cysarpu a aaespenet, mam na to knizku".
Programator by mel umet skriptovaci jazyk, to je samozrejme silna zbran pro rychly vyvoj, mel by take umet nejake komercni prostredi - dnes tedy Javu nebo .NET, ale zaroven by mel rozumet klasice - cecko, kompilace, linkovani, princip volani funkci operacniho systemu.

> Myslim ze jste me trosku nepochopil, pokusim se tedy svuj nazor rozvinout. Osobne nic nemam proti skriptovacim jazykum jako takovym

Tak nevím, ale ten původní příspěvek se snad ani jinak nedal pochopit, než jako útok proti skriptovacím jazykům. Navíc zkušený programátor ví, jak malý rozdíl je mezi PHP a kompilovaným jazykem. V podstatě by stačilo odbourat pouhých pár vlastností (např. eval, $$var) a bylo by možné PHP překládat.

Kvůli překládání EVAL rozhodně odbourávat nemusíte. ;-) Možná by se v něm něco muselo omezit, kompilovat jazyk s evalem ovšem principielně rozhodně možné je. Ale zrovna miniruntime z toho nebude. ;-)

Jako jedna diplomka na MFF byl prekladac PHP, aby sel pouzivat s .NET (snad nevadi, ze to je bytecode)

>>>Programator by mel umet skriptovaci jazyk, to je samozrejme silna zbran pro rychly vyvoj, mel by take umet nejake komercni prostredi - dnes tedy Javu nebo .NET, ale zaroven by mel rozumet klasice - cecko, kompilace, linkovani, princip volani funkci operacniho systemu.

To je jako pokus o definici programátora, jo? Pak věz, že programátor je člověk s přirozeným citem pro algoritmy. Dobrý programátor zná i pozadí (matematika, složitost, vyčíslitelnost, programovací paradigmata...) a alespoň jeden programovací jazyk (+ platformu). To ale není nutná podmínka -- programátoři tu byli, ještě nebyly počítače (a Ty na světě).

Existoval-li by nějaký takovýto (ryzí) programátor, jsem přesvědčen, že pokud by tě snad přijali do nějaké softwarové firmy (pánbůh s nimi) a šel by tam i náš ryzí jedinec, tak by Ti zcela jistě šéfoval. Říkal by Ti, co máš dělat. Už z tvých příspěvků je patrné, že postrádáš mnoho rysů programátora (a možná i rysů logicky uvažujícího člověka).

Nechapu ty pokusy o ironii, muj prispevek rika zhruba to co ten Vas... a nebo ne? Pod pojem "programatorska kultura" v duchu zahrnuju i jiste znalosti teorie, computer science, i kdyz jsem to ve svem prispevku mozna mel zminit.
Cenim si lidi kteri znaji algoritmy a vnitrni princip veci, a ne jenom naucene postupy bez znalosti myslenek ktere jsou za tim.
Opravdu nechapu vase vypady proti moji osobe.

Teď jsem se chytil za nos. Jsem jenom takový anonymní hlupáček a radši si useknu prsty kterými píšu a skočím šipku do vypuštěného bazénu.

Konec diskuse s někým, kdo není schopen rozumných argumentů a posílá příspěvky pod různými neregistrovanými uživateli (viz předchozí příspěvek). Ty "elito" mezi programátory --- jsi jelito :-) H0WK

ps - Příště až budeš chtít zase něco někam napsat, nad svým textem se pořádně zamysli a dvakrát si to po sobě přečti, než něco pošleš. Ušetříš si nekonečné obhajování, že "jsi to vlastně tak myslel".

Nejak tomu celemu nerozumim, o co tu jde? Znite mi jako prechytraly suveren a s takovymi opravdu nemam chut debatovat.
A taky nevim proc mi tykate, neznam vas a ani znat nechci.

Ted jsem si precetl Vas predchozi prispevek a to uz je trochu moc, takova obvineni. Jdete prosim do pr.achatic, vazeny pane.

To ja jsem machr programator a v tom nasem vidlakove sefuju vypocetnimu oddeleni strojni a traktorove stanice chvojkovice brod. Nikdo na me nema a proto te muzu klidne poucovat.

Programator by mel umet skriptovaci jazyk, to je samozrejme silna zbran pro rychly vyvoj, mel by take umet nejake komercni prostredi - dnes tedy Javu nebo .NET, ale zaroven by mel rozumet klasice - cecko, kompilace, linkovani, princip volani funkci operacniho systemu.
Programator, který v rámci své pracovní náplně nepoužívá skriptovací jazyky je umět nemusí, pokud nemusí vyvíjet v komerčním prostředí tak o něm také nic vědět nemusí (proč bych měl proboha .NETit? .NET nemám rád:) etc.
Programátor by měl mít altoritmické myšlení a vědět něco o složitosti. Aby byl dobrý, měl by znát i něco o překladači, kterým se jeho zdrojáky budou překládat. Bohužel je to v současné době právě spíš tak, že lidi se hlavně učí .NET, C#, Eclipse, ale napsat stavovej automat neumí :D

taky se jako UPOLak citim pobouren, tim ze na seznamu "vybornych" skol je treba takove VUT a neni UPOL. obzvlast kdyz vidim, nektere bastlire co vylezou z VUT pisou veci v PHP bez jakychkoliv teoreticky/praktickych zakladu. ale neni to o skole, ale o lidech jestli se chcou ucit, nebo nejak tu skolu prolezou s tim, ze maji diplom... ta skola dava jenom minimalni zaklad...

co se tyce te kvality na upol, bych mel urcite vyhrady vzhledem k poslednimu personalnimu zemetreseni.

k tematu dodam jenom to, ze perl je jeste vetsi splacanina nez PHP a Larry Wall je na to patricne hrdy! nazyva to postmodernim jazykem! navic PHP vzniklo jako zjednodusenina perlu ;] takze ta diskuze me pripada malinko mimo.... kruh se uzavrel...

Tak ty tady v jedny vete valis hamoty o kvalite UPOL a o vetu niz, cituju
"co se tyce te kvality na upol, bych mel urcite vyhrady vzhledem k poslednimu personalnimu zemetreseni."
zase tu udajnou kvalitu popiras?
Toz, uz nehul!

Je to takto - kvalita vynikajicí, ale tento semestr odešlo hodně učitelů, zatím nevíme, jak se to projeví. Rozumný člověk si totiž bude dělat závěry až po určitém čase.

Bylo to víc kantorů, poptej se, ústně ti to někdo jistě podá rád. Jsou tam menší třenice, každopádně to byly jisté šachy.

Jabko, kdy pojede konečně BanánaLinx.kom? :-D

Dobry den,
jsem taky z Olomouce a zajimalo by mne, ktera firma vyviji informacni system pod mod_perlem.
Neco podobneho se chystam taky zavest, tak zjistuji jak jsou na tom ostatni.

Dobry den,
jsem taky z Olomouce a zajimalo by mne ktera z firem vyviji informacni system po mod_perlem.PS:Chystam sa taky na neco podobneho.

To ti tak určitě řekneme ty nádivo. Radit konkurenci aby nám přebrala naše zakázky, tož to my milujeme.

Tento příspěvek opět psal pan co si říká "elita", asi toho bude víc, nemám čas to procházet, ale toto je vrchol ubohosti. Snaží se tady pod nickem "Olomoučan" nebo ".oOo.", pod kterými jsem do tohoto fóra vyjádřil svůj nesouhlas s jeho "výlevy", urážet ostatní, načež mě pak "upozorňuje" na nevhodné chování. Trapné, nemístné, ubohé a slizké.

Aha, tak ty tady diskutujete pod nekolika nicky (jak jste se ted sam priznal) a pak z toho obvinujete nekoho jineho a urazite? Chytry chlapik... dejte si prosim tvaruzky a panaka starorezne a nas highway kingy z Prahy nechte na pokoji. Howgh.

Nikdy jsem si nemyslel, že se budu na novém rootu registrovat, ale tady Petr Zvěřina z Václaváku alias Mr. Jelito, si prostě nedá pokoj s těmi prasárnami.

Teď si zkus něco poslat pod mojí "novou identitou", opičáku :-)))

Umím programovat jen v phpčku a v perlu (a to mizerně). Jsem jenom bezcenný dement a rozhodl jsem se že prokážu lidstvu službu tím že se spláchnu do záchodu.

Dík :-)))

Právě jsi nám všem předložil důkaz, že tady píšeš pod jinými nicky. Obrázek si udělá z tohoto threadu každý sám...

Příště používej hlavu, docela jsi mě překvapil. Myslel jsem, že nenaletíš. Přecenil jsem tě, jelito...

Jdi do prdele ty debile.

Nikdy jsem si nemyslel, - a na co sis myslel ze ta registrace je ? To ti to musel nekdo predvest, aby ti to doslo ?

učil jsem vás vaše vzdělání stálo za h...

no myslim ze clovek ktery programuje v perlu (jazyk matlalu, necitelny) a k tomu jeste v olomouci musi byt opravdu kvalitka

"spagetovy kod" vs. "objektova programatorska onanie", ja davam prednost navrhovym vzorom... :)

Návrhové vzory jsou těšítko pro lidi co neumějí Lisp. Místo toho aby si člověk definoval vlastní syntaxi a vlastní konstrukce pro řešený problém (což v Lispu jde i když to zní na první pohled zvláštně) a pak už je jenom používal tak do omrzení píše stejné bloky kódu "podle vzoru". Uznávám, výsledek je přehlednější než když si programátor tvoří podle svého momentálního nápadu, ale pořád ještě to není ono.
Ti z vás kteří Lisp znají (pan Hegenbart?) mi možná dají za pravdu že návrhové vzory jsou vlastně jistou implementací "higher order" programování, programátorského stylu funkcionálnich programovacích jazyků. Pokud takové jazyky považujete za akademické, pak vězte, že během posledních pár let jejich vlastnosti nenápadně přebírá "mainstream" (viz inference typů a lambda v novém C#).

Ja jsem jiz pred delsi dobou zjistil, ze se lidi toho nazvu "Lisp" dost boji (asi proto, ze je s Lispem strasili ve skole :-). Proto je dobre, ze se mnoha lety overene Lispovske veci z sedesatych let minuleho stoleti objevuji v novych dynamickych programovacich jazycich. Posledni dobou jsem stopu po Lispu nasel zejmena v Pythonu (lambda vyrazy, uzavery, seznamy) a neco take prebira Java a C#.

Tak je to spravne, pokud nezabere celni utok po cele fronte, je nutno provest zdanlivy ustup a naslednou infiltraci :-)

Ty lambdy z Pythonu bohužel zase useknou... ;-)

To jsem ani nevedel. Hmm, takze to zase bude jazyk pro pojidace kolacu :-))) A me se pritom lambda kalkul opravdu libi, minimalne od dob prednasek prof. Hrusky.

Ehm...to jsem byl já. ;-)

Because Python is beautiful and ripe?

Nebo protože Python má vlastní projekty, na kterých se podílí IMHO celkem dost lidí? Nic ve zlém, ale Ruby potřebuje nějaký ten performance boost v tuhle chvíli o dost víc a taky nějaké ty lidi, kteří by se nad tím zamysleli. To už byste rovnou mohl tvrdit, že by byl dobrý nápad začít psát nový a lepší kompilátor Cčka. ;-)

Kromě toho jsem reagoval na to, že panu Tišnovskému se bude v Pythonu stýskat po lambdách. Pokud někdo chce lambdy, tak mu zkrátka nepomůže, že Python je hezký, když i ta současná limitovaná konstrukce je de facto deprecated.

http://wiki.cs.uiuc.edu/VisualWorks/How+to+get+rid+of+Objects+in+Smalltalk

:-D

Úžasný :-)
Potom ještě z Lispu konečně odstranit naprosto zbytečné seznamy snadno nahraditelné páry, to pak nahradit lambda kalkulem a pak jen s blaženým úsměvem sledovat, how David and Vassili get rid of this Universe ;-)

No moment. Já žil v domnění, že všechno, co existuje, je jen funkce jedné proměnné... :-D

:-D

Ahoj Pavle,

takova "uprava" Lispu uz existuje a jmenuje se Unlambda - http://www.madore.org/~david/programs/unlambda/

Pravda, kod byva trosku necitelny, ale zato je to osekane o vsechny zbytecne jazykove konstrukce :-)))

tak trochu míchání pojmů, ne?

The name "goto" is misleading, and often associated with BAD THINGS(tm). Because our proposed solution is not a real GOTO construct, we will instead reuse the "break" keyword, and extend it with a static label.

No to je gól. :-D Raději tomu budeme říkat jinak, protože to jméno má špatnou pověst, přestože bychom tomu dali úplně stejnou funkčnost, i kdyby se to mělo pořád jmenovat GOTO. No to je mi logika. :-D

goto je i v delphi, ale i v tisicech řádků jsem nikdy neměl potřebu ho použít (ani jsem si na něj narozdíl od vb nevzpomněl). procedury, funkce a cykly řešej vše.

... a už zmíněný rekurze.

A co jiného je třeba takový tail call než goto v bezpečném hávu a s argument passingem? Nebo kód psaný v CPS? ;-)

Goto je i v C# .NET

no v delphi pokud vim neni break o vic nez jeden cykl, takze tam se pak goto muze hodit (bud goto, nebo jine ne zrovna elegantni reseni) kdyz chci vyskocit o dva a vice cyklu ... ono delphi myslim nema ani continue ...

jistěže má continue. když už má break a exit, kdyby neměly continue, to by byl nesmysl :)

Zalezi na tom, jak stukturujete program, tj. jak cely problem delite na podproblemy. To, ze je zapotrebi vyskakovat z vice vnorenych cyklu totiz muze znamenat, ze se v jedne procedure/funkci/metode snazite udelat vic veci soucasne a muze byt vyhodnejsi problem rozlozit a treba z jedne smycky volat jednodussi funkci.

Ja vim, "moderni" jazyky maji problemy s predavanim parametru, takze se ten rozklad na podproblemy dela slozite. Je to skoda, protoze napriklad takovy Forth vede prave k systemu programovani "rozdel a panuj" (a tento princip vlastne vedl ke vzniku celeho OOP).

No problem muze byt treba kdyz zpravovavam nejaka tri- ci vice-dimenzionalni data ... to jsou pak min. tri vnorene cykly a nekdy je treba vyskocit o vic ....

Ne vzdy je ucelne drobit to do nejakych podfunkci a cpat tam return ... jednak predavani parametru, jednak nekdy i prehlednost.

Obávám se, že jste to špatně pochopil. Vzhledem k tomu, že vývojáři do jazyka nechtějí dát kompletní GOTO, tak pro tuto konstrukci navrhují jiné jméno. Tím pádem nedojde k tomu, že někdo použije GOTO stejně jako je zvyklý v jiných jazycích a bude se divit, že nefunguje. Dále to nebude svádět psát programy ve stylu Basicu (20 GOTO 10). Pokud by se nakonec použilo kompletně vybavené GOTO (což je vzhledem k probíhajícím debatám docela dobře možné), tak by nejspíš dostalo jméno GOTO.

Ale pochopil, pochopil... Pár jazyků s podobně ořezaným GOTO jsem už, myslím, viděl, a motivace autorů vždycky byla stejná. Ale protože GOTO i v takovém kontextu je pořád GOTO, nikoho to nenapadlo přejmenovat. Já vždycky myslel, že GOTO je nepodmíněný skok na pojmenované nebo očíslované místo programu mimo rámec strukturování kódu do funkcí a pokud tahle jazyková konstrukce dělá něco jiného, strašně rád se nechám poučit, co vlastně. ;-)

A že to jazykově nesedí, to nevadí? "break blah" - copak to přeruší nějaké "blah"? Já myslel že "goto blah" je sémanticky angličtinářsky správně. Ale dneska máme toho newspeaku hromadu, a kromě toho, co si dělá PHP je mi celkem jedno. Jen z toho trošku "unbellyfeeluju" :-D

A i do jazyku, ktere maji pouziti GOTO celkem rozumne omezene (C, Placal) nacpali zli Basicari aspon setjmp() a longjmp() :-)))

Semanticky je to nejhure udelane v Jave, tam aby zakryli, ze break je vlastne GOTO, dokonce umistili label do jine pozice, nez na kterou se skace :-)

No setjmp a longjmp je vic nez pouhe goto, protoze to i ulozi/obnovi stack, cili muzu skakat i nekam uplne mimo aktualni funkci (tedy muzu skakat "vyse" ale uz ne "nize" nebo "napric")... pouzitelne treba nekde pri konstrukci exception handleru nebo podobnych veci (cili streva runtime libraries :o)

call-with-current-continuation je zase lepší než pouhý setjmp a longjmp, protože i uloží/obnoví stack, takže můřu skákat i úplně mimo aktuální funkci, a dokonce i níže a napříč a můžu se do volané funkce vrátit i zpětně. ;-)

"rozumne omezene" jo ? Zkuste si s goto - nebo treba i se setjmp a longjmp - implementovat multithreading ... na druhou stranu, dokud je mozne k C linkovat assembler, neni treba kvuli te jedne funkci na prepinani threadu pridavat jazykovy konstrukt (a prepinat thready jednoho typu ve vic nez jedne funkci je blby napad). Navic jak C, tak packal obsahuji inline assember.

Pokud je GOTO omezene pouze v ramci jedne funkce/metody (+ dalsi omezeni, ktera se tykaji smycek), tak je implementovano stejnym zpusobem jako smycky, akorat tam jsou misto relativnich kratkych skoku typu "jnc", "jz" apod. short jumpy.

Ja vsak nejsem v zadnem pripade zastancem GOTO a ani breaku pres vice smycek - GOTO jsem nepouzil uz peknou radku let a break pres vice smycek stejne neni v C-cku podporovany a v Jave, kdyz na podobnou konstrukci narazim, pouziju Forthovskou zasadu "rozdel a panuj" :-)

Naproti tomu predcasny vyskok z jedne smycky se pouziva dost casto, protoze to nahrazuje vlozene podminky a slozitejsi testy na zacatku/konci.

Takze souhlasite, ze goto je pro nektere ucely omezeno prilis a implementace setjmp a longjmp byla nutna ?

Kdyz uz tak mavate tim assemblerem, zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE. V C obcas musite obetovat trochu teoreticke cistoty kodu tomu, aby to nebylo line jak mrcha. Docela by me zajimalo, jak si s tim poradi Java JIT ...

Oproti tomu break pres vic smycek nahrazuje houf naprosto zbytecnych testu nasledujicich vnitrni smycku.

"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"

...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky.

Co to ocitovat cele ? zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE.

Pro pripad ze by vam to nebylo jasne, napisu to jeste jednou: zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje v ostatnich jazycich (nez je Forth) za obludnosti na tema predavani argumentu do funkce. Rikal jste, ze ho pouzivate v Jave misto vicenasobneho breaku a mel jsem podezreni, ze by jste ho doporucil i v dalsich jazycich, treba v C misto goto.

Cože? Já že používám něco v Javě místo vícenásobného breaku? Jak jste na to přišel? Já v první řadě nepoužívám Javu. :-D I přesto si drze dovolím domnívat se, že bát se občasného použití zapouzdření smyčky do funkce je krásný příklad naprosto nesmyslné předčasné optimalizace.

Mate pravdu, to byl Pavel Tišnovský kdo to pouzival ... ale na principu to nic nemeni, proste o Forthu jsem nemluvil.

Bat se zapouzdrani mozna ano, ale zapouzdrovat pokazde, kdyz chcete pouzit dvojity break, ne. Tedy, jak je u optimalizace obvykle, zalezi na dalsich okolnostech - konkretne treba na poctu argumentu. Osobne me sice nenapada pripad, kdy by zapouzdreni bylo rychlejsi, ale verim ze takovy existuje. Krome toho pokud je vnitrni funkce static inline, muzete spolehat na to, ze ji prekladac vlozi zpatky a tim ziskate "cistci" kod za cenu trochu casu pri prekladu (tedy levne).

A vůbec, ten return taky nahradí vyskočení z vnitřní smyčky. Volání té funkce i návrat z ní jsou jednorázové a já bych se nesmírně divil, kdyby reálný vliv na výkon byl víc než nula celá nula nula nula mravenec.

Co kdyz cela ta smycka je jeste v jedne smycce (ktera je uz v jine funkci nebo z ni alespon nechcete vyskakovat) ?

Tomu trošku nerozumím. Ten return mě přece vyhodí přesně z toho bloku, který chci vynechat a proto jsem ho zapouzdřil do funkce. Vnější smyčka volající funkci nebude dotčena. V Cčku je trošku problém s absencí lexikálních uzávěrů, hodily by se i anonymní funkce, takže obcházení goro přes návrat ze samostatné funkce může být někdy trošku tricky...hmm, další důvody, proč k psaní větších aplikací nepoužívat jazyk navržený především k psaní Unixů... :-D

Nicméně, právě proto v dnešních jazycích goto je. Myslím si totiž, že snaha za každou cenu obcházet goto v jazyku, který není nijak extra čistý ani v jiných směrech je bláznovství. Co třeba tohle?

http://www.cprogramming.com/tutorial/goto.html
http://www.exim.org/mail-archives/exim-dev/2005-August/msg00003.html
http://youngbloods.org/essays/argument_for_goto.html

Chtel jsem rict ze kdyz cela ta smycka je jeste v jedne smycce tak se to nula celá nula nula nula mravenec muze nascitat podle hesla stokrat nic umorilo osla.

Ano, Ccko je jazyk jineho typu nez forth a obchazet v nem goto je nesmysl. Pro vetsi aplikace je to jazyk dobry, ale nikoliv vyborny. Bohuzel obecny vyborny jazyk zatim neexistuje - tim myslim, ze zatimco pro nektere projekty je vybornym jazykem Java nebo C++, pro mnohe je stale nejlepsi C i se svymi nevyhodami.

Uvedena situace je snad docasna a lze ji zmenit vylepsenim java JIT a C++ kompileru.

O Jave jsem mluvil ja a ne Jakub, takze to pada na mou hlavu :-)

Jak uz jsem psal v prispevku nize, predavani parametru je v TECHTO PRIPADECH reseno i v C-cku primitivne pres registry, ve skutecnosti se totiz pouzije inline funkce a dopad na vykonnost to nema zadny. JIT take pouzije inline funkce, takze se zadne casove ani prostorove narocne predavani parametru nekona.

Jinak cecko preklada na ruzne architektury, u nichs se napriklad takove obludnosti, jako je stack-frame ani nedaji rozume pouzit, takze slozitym predavanim parametru (ala x86) se neda argumentovat.

Mozna mate takovy prekladac, ale na linuxu na x86 se defaultne (podle defaultniho ABI) vse preklada se zasobnikovou volaci konvenci (a kdyz to prepnete (mregparm), neprilinkujete libc). x86 sice neni architektura jedina, ale je nejrozsirenejsi. Jak jsem rikal, pokud je funkce static inline, muzete dosahnout toho ze ji prekladac presune zpatky - ale spolehnout se na to nemuzete.

Pri prekladu napriklad GCCckem s parametrem -O3 nebo (pro psavce) -finline-functions se i ve standardnim cecku (tedy zadna pluska ani GNU rozsireni) budou inline funkce hledat a take tak prekladat. Samozrejme, ze bez optimalizaci se na to prekladac vyflakne, ale potom stoji za uvazeni, proc vlastne to cecko pouzivat (flame), kdyz to i v te pitome Jave s JITem pobezi rychleji (a to za me JITko dela i takove "malickosti", jako kontrolu mezi poli apod.).

Ja jsem byl po dlouhou dobu zastancem cecka, alespon co se tyce programu s naroky na rychlost, ale posledni verze JIT ("server" verze) me presvedcuji o tom, ze preklad s analyzou behu programu je pro mnoho veci vyhodnejsi - holt se az za behu zjisti veci, ktere prekladac pri kompilaci "statickeho" zdrojaku nemuze vedet :-)

Pravda, i bez static muze prekladac funkci inlineovat (a nechat jednu neinlineovanou kopii). Nejak doufam, ze to v tom pripade dela jen pro mensi funkce (aby neplytval mistem), ale netestoval jsem.

Posledni CVS verzi Sun Javy jsem netestoval, ale IMHO stale plati, ze zatimco po delsim behu uz je program zoptimalizovany (kontroly mezi poli vyhazene na zaklade zjisteni, ze k prekroceni mezi nedojde a podobne), pri spousteni noveho kodu je porad rezie Javy dost vyrazna. Ano, pro mnoho velkych projektu to nevadi, protoze se to v celkove dobe behu ztrati ... ale obecne to neplati.

On tu neinlineovanou kopii ponechat nemusi, protoze z kontextu vi, ze se ta funkce nikde jinde nepouzije (to samozrejme plati pouze pro funkce deklarovane jako inline nebo static). I funkce nadeklarovane "inline", ktere se prekladaci nelibi, se nemusi linkovat primo do kodu - to ostatne rika i norma. Vzhledem k tomu, ze se mi zatim darilo jako inline funkce delat opravdu kratke kody (klasicke jsou settery a gettery), tak to GCCcko vzdycky prelozilo tak, jak jsem potreboval.

Ja jsem JITko testoval na verzich 1.4 a 1.5, ta jedna-petka mela aplikovane nejake bug-fixy, ale urcite to neni nejnovejsi vec, spis tak o rok pozadu. Ano, ta rezie je opravdu velka, takze pro mensi utility, ktere se casto pousti, se to nehodi (to je jedna z veci, ktera mi na cele platforme Javy hodne vadi). Na druhou stranu napriklad TomCat nebo JBoss spousti Javovske servlety rychleji, nez Apache Perlovske skripty :-).

BTW, vzdycky jsem povazoval kod vylezly z cecka za "neprenositelny" v tom smyslu, ze cecko je vlastne urceno k tomu, aby se mezi platformami prenasely zdrojaky a ne binarky, u kterych se preklad provadi tak, ze se zvoli "nejmensi spolecny jmenovatel" vsech cilovych platforem. Protoze preklad binarky pro predem nezname platformy prakticky vzdy vyprodukuje neefektivni kod, napriklad dnes je porad popularni preklad pro i386, dnesni procesory toho umi podstatne vice (MMX, SSE2, pipelining atd.). Takze distribuce binarky, pokud to tedy neni osetreno nejakymi testy a vyberem spravne vetve kodu podle procesoru (objemova neefektivita), to cecko strasnym zpusobem degraduje, nehlede na to, ze nektere veci nejdou na i386 vubec napsat (napriklad multiprocessing ma podporu v jedne instrukci az i486, ale ten se stejne na platforme PC moc neujal). Z toho vyplyva, ze duraz na efektivitu prelozeneho kodu je na uzivateli (resp. jeho spravci), ktery by mel preklad provest tak, aby to bezelo co nejrychleji (-O3, -march atd. atd.).

Nebo se na celou efektivitu muzeme vyflaknout a pouzivat moderni i lety osvedcene dynamicke jazyky, ve kterych se aplikace pisou mnohem rychleji nez v cecku a nehrozi pritom to, ze jsem zrovna nedavno objevil v jedne bezne prodavane aplikaci za cca 120 000 Kc dosti usmevny memory leak.

"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"

...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky.

Jasne, goto je v C-cku omezene a je to tak dobre, o tom se snad nehadame :-) Implementace v assembleru je velmi podobna smyckam a podminkam, takze zadne "prasarny" navic se nekonaji, v tomto by taky nemel byt problem.

V C-cku je predavani parametru v _TECHTO_PRIPADECH_ stejne jako ve Forthu, alespon u slusnych prekladacu. Jde o to, ze ty volane procedury/funkce jsou v 99% tak primitivni, ze se stejne vsechno preda v registrech a vlastne o predavani nemuze byt rec, protoze se prelozi jako inline.

Opravdu jde pouze o cistotu kodu, vsechnu spinavou praci nechame na prekladaci ci JIT.

Kdyz jsem u toho JIT: zrovna pred cca dvema tydny jsem neco podobneho zkousel kvuli porovnani rychlosti Javovskeho a C-ckovskeho kodu. Vypadalo to asi takto:

for (int j=0; j!=10000; j++)
    for (int i=0; i!=10000; i++)
        for (int k=0; k!=10000; k++)
             volejfunkci(i,j,k);
// sorry za ty !=, maji tam byt mensitka, ale Root to zdrbe

C bez inline funkci bylo samozrejme neskutecne pomale, ovsem s inline funkcemi se rychlost ceckoveho a Javovskeho kodu uplne srovnala (rozdily cca 5%), takze JIT uz automaticky inline funkce rozezna, a to bez jakychkoli modifikatoru (zadne final ani static).

Uživatel s přezdívkou Olomoučan je totální blb a otrapa. Chlubí se studiem jakýchsi teoretickým bludů a přitom je to jen obyčejný patlal v php a perlu za pár korun. Navrhuju ho anihilovat, nebo rozpustit do syrečků.

přestože interní kódování PHP 6 bude UTF-16, tak jeden znak bude moci zabírat dva nebo čtyři bajty
To už tak u UTF16 bývá.