Názory k článku
Perl pro zelenáče je nová kniha od Pavla Satrapy, je ke stažení zdarma

Souhlas. Mám vydání z roku 2000, v práci i doma, a oba exempláře už jsou "pěkně omazlené".

reknete ze uz v tom nikdo nezacinate novy projekty.. ze ne...

a proc ne?
kdybych potreboval zpracovavat hodne textu, to by bylo asi prvni po cem bych sahl, pokud si nevystacim klasikou svatou trojici (grep/sed/awk)
:)

V tom pripade uz se vyplati jakykoliv ... moderni... (citelny :) ) jazyk?

https://external-preview.redd.it/zttzw4bugI9UCo0PGG8LQc7XAOWiWfhLEkjzXhzDPKo.png?auto=webp&s=a0f3c56a3d20afb44ced7d97978f93ce417a6b15 line 9+10:)

BTW: ze slova 'moderni' dostavam posledni dobou koprivku - obycejne to totiz znamena nejakou frikulinskou nelogicnost, az zrudnost, co nema zadny vztah k lety zavedenym postupum ...
a obycejne to vytvori clovek, co neni schopen se naucit neco 'stareho', tak to rovnou predela podle sveho a oznaci to jako 'moderni'.

souhlas. Obcas mi nekdo rekne ze potrebujeme neco predelat aby to bylo lepsi. Ve finale to ma vice kodu k udrzbe, vetsi naroky, rychlostne je to horsi, ale je to moderni a nesplnuje to nektere puvodni pozadavky.

Připomínáte mi mého bratra, co ještě do nedávna používal Windows 2000 a dodnes vyvíjí v C++ Builder z roku 2003 :-) Máte nějaký příklad té "frikulínské nelogičnosti"?

A preco nie? Vyvoj je rychly, prostredie stabilne. Perl pouzivam na rozne veci na embedded linux. Desiatky tisic riadkov kodu. Frci to rychlo, setrne k pameti a dlhodobo stabilne. Tak preco nie Perl??

A cem bys' napsal script, ktery ma bezet na RHEL4,5,6,7, HP-UX 11.x, popr Solaris? Setrvacnost v IT je obrovska, ani Korn shell neni sam se sebou kompatibilni, a pro Python 2.4 nejsou knihovny.

Přece BASH :). Běžné dělám projekty Solaris 9,10,11+AIX 5,6,7+SLES 10,11,12,15

Ta kniha je nova uz asi 20 let a perl imho dnes nema co nabidnout.

Jen moje zkušenost:
Nejvíc Perl nenávidí ti, kteří se jej nikdy pořádně nenaučili.
Jen můj odhad:
V této diskusi to nebude jiné.

Nemam k zadnemu z jazyku (krome dnes hojne rozsireneho HovnoScriptu, predevsim na webech) zadne emoce nemam. Mimochodem nikdy jsem nemel potrebu ucit se Perl a nemam ji ani ted.

Já se hlásím, že jsem se Perl nikdy pořádně nenaučil - a nenávidím ho.
A jednozančně to souvisí. Perl je velmi těžký na naučení. Zbytečně těžký. Těžší, než jiné jazyky, kterými dosáhnu podobného výsledku. Možná to v 90. letech bylo jiné, já se k Perlu dostal o dekádu později.
Nikdy jsem nechápal jazyky s úspornou syntaxí, kdy stejný příkaz napíšete pomocí poloviny znaků. To je "skvělé", že ušetříte místo při skladování zdrojáků a kapacitu sítě při jejich posílání na server, když si kvůli tomu musíte pamatovat úplné šílenosti ve kterých pak snadno uděláte chybu.
Ještě bych chápal tu šílenou syntaxi, kdyby to měl být jazyk, který člověka pracovně vytíží na 100 % - pak se dá chápat, že si to časem zapamatuje a každodenním používáním to tam zůstane. Ale je to skriptovací jazyk - něco u čeho se předpokládá, že v tom člověk občas udělá nějaký specifický úkol a pak se dál věnuje své hlavní práci (vývojářské, adminské, jiné).

Když otevřu zdroják v jazyce, ve kterém jsem 10 let nedělal - a je to jazyk s ukecanou syntaxí, tak se do toho rychle vpravím, sem tam se potřebuji podívat do něčeho jako je referenční příručka, ale není to často. Když otevřu zdroják v Perlu, tak jsem ztracen. Každou chvíli tam mám moment - a tohle je proboha co?

Basic (8bit mz800)-> fortran77 (TNS AT) -> turbopascal (mz800) -> perl (sgi indy, intel, sparc), a pak uz jen vzdy a vsude python

Ono ve vice lidech psat a opravovat casti kodu v perlu je temer nemozne, rychlejsi a levnejsi je to malem pokazde
napsat znovu.

Alespon v dobe, kdyz vybehl python, perl vubec nemel praci s vyjimkami, rozumnou podporu kodovani (nemluve o unicode), objektu a naopak mel mnoho dalsich nectnosti, navic na intel vs sgi vs sparc se choval pokazde jeste vic jinak, nez ten python.

Pamatuju dobu, kdy A+1 bylo obcas "A", obcas "1", jindy zase 1, a nekdy dokonce i 66 :-)

Zrovna před několika týdny jsem předal svému pokračovateli údržbu poměrně komplexní aplikace napsané v Perlu, na které jsme s kolegou, kromě jiných projektů, dělali s přestávkami skoro 10 let. Potřeboval jsem si uvolnit ruce...
Jde o software pro testery, je to propojené s verzovacím systémem atd...
Při předávání nevznikl žádný podstatný problém. Víte proč? Je to psáno velmi srozumitelně a přehledně. Samozřejmě existuje i dokumentace.
Psát jako prase a puberťák můžete v čemkoliv - nejen v Perlu. Protože Perl pořádně neznáte, posuzujete to nejspíš jen podle pár prasečin, které jste si stáhli z nějakých webů.

Kdybych byl ignorant, mohl bych úplně stejně hulákat, jak je třeba ten Python strašný. Záminka by se jistě našla - kupříkladu syntaxe, která vyžaduje vytvářet bloky pomocí odsazení se dá považovat za slušné zvěrstvo, za které by autor měl být aspoň na 2 hodiny pověšen za k... do průvanu.

Pokud ve svém kódu neodszujes bloky textu tak čitelnost nebude zrovna valná. Nehledě na jazyk.

Umi nekdo vysvetlit, proc jsou soubory MOBI na "knihy.nic.cz" jsou mnohem vetsi nez soubory EPUB? Myslim si, ze by to melo byt obracene, protoze do mobi neni treba pridavat ceske fonty...

Google funguje jen tehdy, kdyz vite na co se zeptat...
Moje zkusenost byla, ze knihy v mobi jsou mensi nez epub knihy, jednim z duvodu byla prave nutnost davat do epub ceske fonty. Predpokladal jsem tedy, ze knihy.nic.cz ma spatne nastaveny generator mobi. Jeste kniha "IPv6" v mobi je mensi nez v epub. Ale ten odkaz "vellum" naznacuje, ze dnes do mobi dava spousta zbytecneho balastu...

To, ze je dnes v mobi souboru ulozen i zdrojovy "epub" znamena, ze mobi format by mel jit cist i na epub ctecce. Pravdepodobne to ale zadna neumi...

Toto je take zajimave, v mobi je ulozen i log o konverzi... :-(

$ strings perl_pro_zelenace.mobi | grep -i prcgen

Protože EPUB je jednoduše hloupý ZIP soubor. Program, který chce EPUB knihu zobrazit s tím má docela dost práce, protože EPUB formát je dělaný na to, aby byl jendoduchý - a čtečka pak toho musí udělat velice mnoho. Není to moc efektivní formát pro knihu.

Jak EPUB, tak MOBI uděláte ze stejného zdroje. EPUB vyrobíte jednoduše tak, že zdrojové kódy zkomprimujete ZIPem, je to relativně přímočarý a hloupý formát. Vznešeně se tomu zazipování říká OCF (Open Container Format).

MOBI je třeba vyrobit složitěji skrze kompilátor, byť zdroj je téměř stejný.

MOBI je formát dělaný pro čtečky mnohem lépe. Je předkousaný tak, aby pro čtečku byl efektivní. Podle verze se liší, co všechno je v něm předkousáno, a jaké jsou jeho možnosti. Hodně jde také nastavit v kompilátoru, který MOBI knihu vyrábí. Velikost MOBI knihy hodně závisí na tom, jaké se použijí přepínače u kompilátoru - u mých knih je MOBI většinou menší než EPUB.

Kromě toho dnes MOBI soubory často obsahují knihu ve formátu MOBI i AZW3 zároveň - takže často jsou to dvě knihy v jedné. Což je také defaultní nastavení kompilátoru.

Tady je hlavni problem v tom, ze "knihy.nic.cz" primarne vytvari epub a ten se pak konvertuje pomoci nastroje "kindlegen" od Amazonu. A Kindlegen ve verzi 2.x zacal delat veci drive nevidane :-(. Z nejakeho duvodu se tak do "mobi" ulozi krome dvou verzi "mobi" take zdrojove kody ePub. Otazkou je, proc tam ten ePub je, zda je to proto, aby mobi mohli snadno otevrit i ePub ctecky nebo proto, aby slo snaze vystopovat piratskou verzi knihy...

Nasel jsem online sluzbu, "zamzar", konvertuje take epub do "mobi" a vysledny soubor je mensi nez ten, ktery vytvori "kindlegen v2.9". Ale porad je ten soubor vetsi, nez co generoval kindlegen v1.2 (ten byl zrejme jeste pouzit na knihu IPv6.mobi).

I novy kindlegen lze donutit k vytvoreni mensiho souboru, podobne velikosti, jakou ma soubor od "zamzar", je treba pouzit tajny parametr "-gen_ff_mobi7".

Jeste vcera jsem si myslel, ze novy Amazon Kindle obsahuje vice Flash pameti proto, aby se do nej veslo vice knih. Jak jsem se mylil! Je to proto, aby se tam vubec nejake knihy vesli.. ;-) Zmeny v "mobi" souborech jsou jen dalsim dukazem, ze svet IT se ubira spatnym smerem...

Tvoje starosti bych chtěl mít. Ježíšmarjááá, knížka má tři MB. Konec světa! Hrůza! Jsme vyřízení!

To byla důležitá informace a bylo nutné ji sdělit, avšak navrhuji, aby od této chvíle byla další jednání vedena těmi, co mají mozek větší než angrešt.

Což je přesně co jsem napsal.

1) Že záleží na verzi kompilátoru.

2) Že většina autorů prostě jen slepě a bez parametrů předhodí kompilátoru EPUB. Výsledkem je, že má ve výsledném MOBI všechno včetně zdrojových souborů, debug informací a dalšího. A také tam má knihu ve formátu MOBI a knihu ve formátu AZW3.

Přímo a bez okolků: Když se ten, kdo MOBI vytváří na to vykašle, výsledkem je obří MOBI soubor. A to se dělo i v tomto případě, stejně jako ve většině případů jiných, kde se primárně vytváří EPUB soubor a s MOBI se nikdo moc nepáře.

Jinak řečeno, větší velikost MOBI souborů není vlastnost formátu, ale ignorance většiny těch, kdo MOBI soubory vytvářejí. Vzhledem k tomu, že MOBI nutně nepotřebuje (na rozdíl od EPUB formátu) ukládat žádné XML soubory ani jiná zvěrstva, ale opravdu jen čistý text a další atributy v přímé podobě - při pečlivé práci je MOBI obvykle kratší než EPUB.

A to je to, co jsem napsal.

>> "Jeste vcera jsem si myslel, ze novy Amazon Kindle obsahuje vice Flash pameti proto, aby se do nej veslo vice knih. Jak jsem se mylil! Je to proto, aby se tam vubec nejake knihy vesli.. ;-) Zmeny v "mobi" souborech jsou jen dalsim dukazem, ze svet IT se ubira spatnym smerem..."

Amazon Kindle už MOBI nepoužívá. Rozvíjí nový formát AZW3 už od roku 2007.

Geneze je taková, že EPUB i MOBI je v podstatě jen prekabátěné HTML/CSS. AZW3 už přidává mnoho věcí, které potřebují knihy a v HTML/CSS nejsou.

Problém paměti je, že pro zpětnou kompatibilitu je v MOBI souboru jak verze MOBI, tak AZW3 - takže knihy dvojnásobně nabudou na velikosti. Ručně si můžete vyrobit jen čisté MOBI nebo jen čisté AZW3, není to problém.

Jinak řečeno, pokud chcete, tak máte mnoho možností, které v EPUB nejsou. Proto třeba já už e-knihy roky vyrábím tak, že je vyrábím pro Kindle, čímž získám věci a kvalitu, kterou transformací skrze EPUB získat nelze. A EPUB pak, jakožto nižší formát, získám konverzí z AZW3.

Ale myslím, že už jsme dost off topic.

V Perlu bylo a myslim ze jeste bude hodne napsano. Jedna se o nejctivejsi a nejzabavnejsi ucebnici nejen Perlu jakou jsem kdy cetl.

Na tohle je Satrapa výbornej. I jeho přednášky a cvíka stály za to!

A co místo toho nabízíte?

Něco co má tak rozsáhlou základnu obstojně fungujících a testovaných modulů jako má perl na CPANu a současně něco u čeho nemusíte s každou novou verzí interpretu trnout jestli několik let staré skripty budou ještě fungovat.

Nechápu, kde se ta nenávist k Perlu bere. Skvěle se v tom píše, má to moderní OO a frameworky a tuny hotových CPAN modulů. Co v tom napíšu, funguje všude. Za mě jednoznačná volba.

Copak psaní, to je dobré. Ale jak říká klasik "Perl is a write-only language" :-D

Mno neviem. Aj ked sa po rokoch vratim ku svojim scriptom nenam problem ich pochopit. Prikladom write-only jazyka je skor povedzme brainfuck. :-)

vicemene souhlas, pokud kod neni okomentovan, pokud neznam autora.
ale pokud se pracuje v teamu*, pokud se domluvi na urcitem 'dresscodu' a hlavne, pokud se pisou komentare do kodu (vcetne kontaktu na autora prislusne casti, nebo odkazu na zdroj inspirace), tak to opravdu neni zle.

*team: neni tim pojmem myslena banda individualistu zmergujicich dohromady svoje casti kodu, ale lidi, co mezi sebou komunikuji, diskutuji, domlouvaji se, sdileji svoje poznatky i predstavy, ...

Niektoré jazyky bránia praseniu viac, niektoré menej. Perl žiaľ necháva praseniu voľný priebeh, ba priam ho niekedy až podporuje.
Ale maslo na hlave má ten, čo prasí. Aj Perl sa dá písať čitateľne.

Oracle má v Perlu prakticky všechny scripty pro jejich databázi. Když se na ně člověk podívá a nevšimne si koncovky, tak to na první pohled jako Perl ani nevypadá. Je to hezky strukturované a čitelné. Bohužel o většině jiného kódu v Perlu, co jsem potkal, se to říci nedá. To vypadá spíš jak soutěž o co nejkratší sled znaků, který produkuje požadovaný výsledek.

@kolcon : mam pocit, ze jedinym argumentem je, ze je stary :-D
je to jazyk umoznujici delat kod ne jenom jednim zpusobem, a nektere (mlade?) to provadi primo k neskutecnemu zoufalstvi, az pocitu menecennosti.
ztraci jistou pudu pod nohama ... tak zuri a nenavidi to, co jim bere pocit bezpeci a jistoty sve dokonalosti.
navic, kdyz lpi na svych zasadach citelnosti kodu (clean code), zaroven je nic nenuti ty zasady dodrzovat, nemaje pevnou vuli psat stejnym zpusobem a konzistentne v celym projektu po delsi dobu, komentovat, co napsali a vysvetlovat, ... tim padem produkuji praso-kod, co zas zapricinuje cerne nalady, zoufalstvi u svych kolegu ...
takze to tvori nekonecny kruh zoufalstvi a beznadeje
;)

Perl ztratil půdu pod nohama nekompatibilním přechodem mezi Perl 5 a 6. Nejde ani tak o ten přechod, jako že se ztratila zpětná kompatibilita, a jako že trvalo mnoho let, kdy nikdo pořádně nevěděl co bude s Perlem. Bylo jasné, že Perl 5 se nebude rozvíjet, a Perl 6 dlouho nebyl. Tím si podepsal ortel.

Na druhé straně opravdu dnes nechápu, co někoho vede používat Perl, kromě toho, že ho zná z minula. Ten jazyk prostě není zrovna ideál.

Já jsem měl před mnoha lety koupenou knihu od Satrapy, která se tu zmiňuje. Ta kniha je vynikající a nelze než panu Satrapovi vzdát hold za jeho práci a knihu. Ale hlavní co jsem pochopil po té knize je, že Perl je jazyk, ve kterém opravdu dobrovolně programovat nikdy nechci. Ne proto, že by byl těžký či bych ho nezvládal, ale protože neumí nic speciálního, proč bych Perl měl potřeboval, a mnoho jiných programovacích jazyků je mnohem lepších.

Perl je jeden z tēch nových senzačních zbytečnýcu jazyků které sebou přinese každá nová generace koderu. Od čobolu k pythonu.

Neni to novy ani zbytocny jazyk, ale uz vyse 30 rokov dokazuje svoju uzitocnost. Kto sa ho chce naucit, tomu moze pomoct tato vynikajuca Satrapova kniha.

Perl je jen další z mnoha stovek univerzálních jazyků na jedno brdo, kterých najdete na každém rohu tucty. Vlastně jsou to dnes dva jazyky Perl 5 a Perl 6. Navíc s klesající popularitou a zamotanou syntaxí.

Kniha od Satrapy je ovšem vynikající, všechna čest.

Tou formuláaciou "je jen další z mnoha stovek univerzálních jazyků na jedno brdo" sa akoby snazis z nejakeho dovodu Perl degradovat :-)
Ked sa podivas trochu do historie, tak Perl je jeden z prvych pouzitelnych skriptovacich jazykov.
Pre novsie skriptovacie jazyky sluzil ako inspiracia toho, aku funkcionalitu ma dobry skriptovaci jazyk obsahovat - mInimalne co sa tyka datovych struktur (zoznamy a asociativne polia) a regularnych vyrazov.
Z praktickeho hladiska: dnes byva Perl 5 nainstalovany skoro na kazdom systeme - podobne ako napriklad kompilator C. Podla mna Perl 5 ma medzi skiptovacimi jazykmi podobne miesto ako jazyk C medzi programovacimi. Je to zakladny skriptovaci jazyk, ktory sa oplati naucit.

K historii: Co bylo za Rakouska-Uherska je pro dnešek už vcelku jedno.

Perl se uchytil jako náhrada omezené programu awk pro filtrování textových souborů. A také proto, že dlouhou dobu existoval mod_perl do Apache, a daly se v tom psát CGI webové skripty.

Rok 2000: Pak to ale Perl potentoval, když jeho autor Larry Wall prostě vyhlásil nekompatibilní změnu z Perlu 5 na Perl 6. Dlouhou nikdo nevěděl co bude, a tak Perl zažíval odliv zájemců, a ten odliv trvá dodnes. Protože Perl není žádný speciálně skvělý jazyk, aby byl potřeba pro nějakou oblast, a bez Perlu není problém se obejít, tahle epizodka ho likviduje, a postupně ho zlikviduje.

Perl nemá žádnou oblast použití, kde vysloveně exceluje, nebo kde by byl urgentně třeba. Zastoupí ho na jeho místě bez problém 100 jiných jazyků. Dnes lidi oceňují udržovatelnost a čitelnost zdrojového kódu - a to jsou zrovna velké bolístky Perlu.

To je problém univerzálních jazyků, že prostě chvíli jsou na výsluní a jejich použití jde spíše podle módy. Perl nikde v žádné oblasti použití neexceluje, tudíž mu potenciálně konkuruje obrovská spousta stejně zaměřených jazyků.

Mozna drivejsi, rozhodne ne stavajici. + argument proc je perl zastarala technologie.

Pamatuji se na linuxovou konferenci v r2006, kde se ptali Petra Krčmáře, jestli může dát k dispozici redakční systém používaný na root.cz. Řekl něco ve smyslu že to není šťastný nápad a řešení není úplně ideální. Předpokládám, že se jednalo o onu perl verzi ... a důvod proč už nová verze na perlu nevznikla.

Shrnutí předchozí diskuse:

1/68 - poděkování za informaci
4/68 - stížnost, že kniha není nová
16/68 - hekání na téma epub má 3MB
47/68 - flamefest na téma Perl, s exkursem do historie Root.cz, trendů webdesignu apod.

Nějak mi v té statistice chybí výlet do Rimmerosvěta, který začal Lol Phirae.

Když jsem hledal práci linux admina před 15-ti lety, ptali se, jestli umím programovat v perlu.
Když jsem ji hledal před 5-ti lety, ptali se, jestli umím programovat v ruby.
Když jsem ji hledal vloni, ptali se, jestli umím programovat v pythonu.

Mám zcela vážně míněnou otázku. Jaký jazyk by byl lepší než Perl pro zpracování velkého množství textů pomocí regulárních výrazů? Musí to umět utf-8, ty regulární výrazy musí být jakž takž čitelné a nesmí to být pomalé jak šnek.
Doposud jsme používali flex - je rychlý, ale dost nečitelný a kvůli utf-8 jsme museli udělat dost šílené úpravy. Perl není tak rychlý, ale po optimalizaci to nebyla taková katastrofa a ty regexy se v něm píšou dobře.

Myslim, ze jednou z nejvetsich prednosti Perlu (ktera v diskusi nezaznela, ale v knizce na ni p. Satrapa narazi) je rychlost, s jakou vyprodukuji funkcni/prezen­tovatelny vysledek. Klidne to muzu pojmout jako prototyp, co predvedu zakaznikovi (kouknete, takhle by to mohlo fungovat, libi ?) a pak to treba neboucham v C/C++ nebo cemkoli jinem si bude prat.

Na jednu stranu mam k dispozici skriptovaci jazyk s volnou syntaxi, regularnima vyrazama, asociativnima polema a na druhou stranu ho mohu pomerne snadno integrovat s vecma v okoli (neni problem volat funkce v ceckovych knihovnach, ovladat pres OLE/DDE aplikace tretich stran na widlich, ci jakoukoli jinou nestandardni vec). A k tomu je tu milion hotovych reseni pristupnych pres CPAN (napr. pro praci se siti, konverze formatu ... atd.)

Myslim, ze na tvorbu funkcnich prototypu reseni je Perl stale neprekonatelny. Ktery jiny programovaci jazyk mi toto (se stejnou rychlosti produktivity) nabidne ?

Se vším souhlasím, ale unless je prostě zlo. Člověk čte řádek zdrojáku a na konci zjistí, že je to celé naopak. Skoro jak s němčinou :)