Názory k článku Úvod do skriptování v Linuxu

Pro PHP vývojáře je jednodušší napsat místo shellového skriptu PHP skript :) Nevidím důvod proč by se PHP nemělo pro psaní shellových skriptů používat

me se php na systemove skriptovani vcelku osvedcilo - napriklad generovani pdf z textovych podkladu a automaticky tisk (njn, kdyz uz ma prijit upominka, tak at je aspon hezka, ze?). potesilo me, jak to slo lehce.

Niekde tu na root.cz bol dokonca clanok o skriptovani v PHP.

To já bych jí celkem chápal. Jazyk, který nepoužívá namespaces, a má tedy v "root namespace" potenciálně tuny klíčových slov. Jazyk, který používá syntaxi moje_funkce, MojeFunkce i mojeFunkce. Jazyk, kde se píše array_search(co, kde), a strpos(kde, co) - tedy bordel v pořadí parametru i syntaxi. Jazyk, kde je pro MySQL interface mysqli a mysql (samo o sobě nekoncepční), a používá se mysql_query($query, $db) a mysqli_query($db, $query).

Používání PHP těžko obhajovat tím, že ho psali amatéři. To může věc vysvětlit, ale nikoliv omluvit, natož nedostatky eliminovat.

Vše co uvádíte jsou jen samé kosmetické prkotiny. Kdo má k programování vlohy, tomu to nemůže vadit, kdo ne, tomu by jejich nepřítomnost stejně nepomohla.

Kdo ma k programovani vlohy, tak dela v PHP pouze pokud je k tomu donucen okolnostma, protoze jak pozna jazyky rozumnejsi jazyky, tak da od PHP ruce pryc a uz snim radsi nechce nic mit.....

Presne tak!

A i toto:
> PHP, které patří na weby a na systémové skriptování se příliš nehodí, o programování složitějších
> aplikací ani nemluvě.

naznacuje, ze autor PHP nezna. Kdyby vedel co vsechno se v tom da udelat..... a jak.

Miluju to! :) Kazdy do PHP sije, ale v dalsi fazi zjistim, ze o PHP nema ani paru a ze nadavat na PHP je proste IN, tak nadava.

Jiste - je cela rada cunatek, co prave zjistili k cemu je echo a if a zacnou "programovat".... Pak je to utrpeni..... Ale to uz jsem videl i jinde. PHP ma povest jednoducheho nastroje a tak pred nim cela rada zacatecniku nema "posvatnou uctu" (jednoduse receno) a rada mazaku ho bez rozmyslu zavrhne.

Pravda je ta, ze PHP lze pouzivat "jednoduse" a i cunatko si v tom udela co potrebuje. Ale moc dobre vim, ze PHP dokaze byt i velice mocny nastroj. Sam mam par zarezu predstavujicich opravdu hodne velke projekty v PHP...... To prosim nemluvim o nejakem CMS a podobne....

A fajn je, kdyz znate streva PHP/Zendu a muzete si udelat sem tam nejaky modulek, sem tam pouzit Zend do jine aplikace....

PHP JE FAJN a je pouzitelne na celou radu veci!

Já mám osobně vždy po ruce MS Excel. V něm se dá udělats spousta věcí, a ve vestavěném VBA ten zbytek :)

Správně! Proč by nemohl být BASIC tím pravým ořechovým - hlavně když to uklohnili v microsoftí kuchyni, je to pro LO dostatečným důvodem k jásotu.
Že vás to ještě baví, vy za to opravdu musíte být placený. Je to jako by byl někdo placený za to, že do vědeckých diskusí neustále píše, jak evoluce nefunguje a jak je země placatá a spočívá na hřbetě obrovské želvy.

Ja tiez som parkrat pouzil PHP na spracovanie textu a nemozem si stazovat. Inak by ma strasne zaujimalo ze preco sa podla autora PHP nehodi na vacsie projekty. Poznam par informacnych systemov urobenych v PHP a verte tomu ze maju o cca 80% nizsie HW naroky ako nieco urobene v jave s rovnakym rozsahom. Vela veci je o sposobe programovania a nie o programovacom jazyku.

Javaci vacsinou programovat nevedia a spoliehaju sa na to, ze ich produkt je dobry preto lebo je spraveny v jave.

:) to potom ja mozem pvedat ze, zamestnat ako progrmatora cloveka co nerobil v nicom inom ako php je dost velky risk. Programovat viem, a myslim ze na vacsich projektov php nema vo vykone proti jave sancu. Samozrejmne da sa aj jave pisat neefiktvne, ale oproti php mam k dispozii singletony, mozem si cachovat casto pouzivane veci, a vdaka jit je java aj celkom rychla.

Heh, no tak zamestnat programatora, ktory robi iba v jednom jazyku je dost velke riziko - ci je to php alebo java...

Java je sice v konecnom dosledku rychlejsia ale ma ma vacsie HW naroky pri vsetkych tych vrstvach a doplnkoch co potrebuje aby sa v nej nieco vyprodukovalo.
Cachovat sa daju aj php skripty, akurat sa nedaju cachovat data, co je niekedy dost na skodu.

A myslim, ze okrem bankovych IS v SK alebo CZ sa nerobia take robustne systemy ze by vyzadovali javu. Ja sa teraz celkom zacinam zaujimat o Python.

Mimochodom tu su benchmarky pre porovnavanie jazykov :)

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=java

mam takeho kolegu a ide ma niekedy slak trafit :) Java mozno ma o nieco vyssie naroky ale ako hovorim zavisi aj od aplikacie, napr. abclinuxu.cz nebezi na nejakom super silnom stroji a ide dost rychlo. Prave robim na jednom celkom robustnom systeme, ktory je pisany v Jave, a neviem si nieco podobneho predstavit v php. V php mi chyba poriadny ORM framework, a poriadne OOP, a vseobecne nedoverujem slabo typovym jazykom.

Pokud myslime oba stejne singletony, tak je lze pouzit i v PHP, obdone factory a dalsi patterny, abstract tridy ci metody, interface apod. Stejne tak i cache. Celkem mocne jsou veci z PECLu a ono i PEARu, ale bohuzel o nich vetsina lidi "programujicich" v PHP ani nevi. Napr. pro cache je celkem rozumne reseni memcache daemon, pro ktery je v PHP wrapper. V PHP lze celkem slusne psat i GTK aplikace. V glade se navrhne GUI a v PHP se jiz jen importne XML + autoconnect na obsluhu eventu. V jedne firme, kde jsme delal, meli aplikaci pro zadavani dat do DB v Accessu (ja vim, des). S pribyvajicimi daty se stala nepouzitelna. Stacilo ji prepsat do PHP-GTK + mySQL a mohla byt vyuzivana i na PC, ktera byla jinak urcena pro vyrazeni. Bylo pouzivano i genrovani XLS ci PDF reportu z accessu. Puvodni doba behu nekolik hodin (DB radove v GB), po prepsani do PHP radove desitky minut. Jasne, srovnavat s MS mozna neni uplne fer, ale bylo spis jako priklad pouziti. V PHP lze bez problemu napsat i daemona. To jsem napr. pouzil pro "cache" dat. Apache request se pres local socket pripoji na PHP daemona, ktery si drzi data perzistentne v pameti a provede nad nimi operaci, jejiz vysledek vrati puvodnimu requestu. Do daemona se implementovala i cast vyuzivajici runkit a tak je mozne se pres "admin port" pripojit a predat mu pozadavek napr. na pridani nove class, metody, upravu stavajicich apod. a to bez nutnosti restartu serveru. Idelani pro aplikace, kde je jakakoliv nedostupnost kriticka. PHP jsem pouzil i pro psani aplikace nad ncurses, opet bez problemu. Existuji pro nej profilery, debuggery (apd, xdebug), moznost debuggovat napr. i ve VIMu :) Diky tokenizeru existuji nastroje pro vytvoreni UML z existujiciho kodu, nebo naopak pro vytvoreni "kostry" z UML. Z javy prevzaty PHPDoc nebo PHPUnit pro unit testy. S moznosti generovani agilni dokumentace ci propojeni se Selenium RC pro testovani weboveho interface "simulovanim chovani uzivatele". Jde jen o to, jestli chce clovek brat PHP jako plnohodnotny jazyk nebo berlicku pro lamy. Ale ma samozrejme i sve chyby. Nekonzistentni naming convention (dano historickymi duvody), zpetna nekompatibilita, hlavne mezi major verzemi, apod. PHP obcas pouzivam i jen v CLI pro drobna zpracovani textu, vypocty apod. Ale vetsinou spis grep, gawk, sed, tr a haldu pipes :)

S dovolení srovnání s MS Access je naprosto mimo, pokud je jako backend použit MS Jet. Architektura je pak podobná nejvíce FoxPro for DOS, jenom UI je v grafice.

A naopak pokud je jako backend použit běžný DB negine (třeba MS SQL Server), je MS Access coby front-end poměrně rychlý. Výhodou navíc je, že VBA umí každý, kdo se naučil psát makra v MS Office.

No ja jsem mel taky podobny napad, ze by nebylo spatne mit systemove skripty v PHP, protoze to vypadalo fakt pohodlne. Jenomze to jsem se staral o 5 serveru, na vsech stejna verze Debianu a PHP a fungovalo to krasne. Jenomze ted je tech stroju pres 60 a mit dulezite systemove veci v PHP, asi by z toho bylo akorat boleni hlavy. Navic je mi proti mysli mit treba na mailserveru PHP (zbytecny balicek na instalaci, zaplatovani,...)

Pokorne jsem se vratil k /bin/bash. Mezi Bashem v Ubuntu Feisty a treba Debianu Woody je sice rozdil, ale az na par detailu mi zatim vzdy vsechno fungovalo. Problemem jsou spise ruzne verze externich nastroju a nepohodlne "propojovani" s MySQL (sed, awk, apod. jsou nekdy pekna pakarna). Zatim jsem ale neobjevil zadnou lepsi nahradu, kterou bych nasel na prakticky kazdem stroji a ve vetsine distribuci. (pouzivam sice jenom Debian/Ubuntu, ale jeden nikdy nevi).

Perl většinou bývá všude. Kdykoliv bych musel použít awk, tak sáhnu raději po perlu, přijde mi to přenositelnější, protože perl je jen jeden a awky byvaj na ruzných systémech ruzný.

To ale porad nezarucuje, ze vsude bude ten POSIX kompatibilni awk. PERL mi v tomdle prisel takovej jistejsi a navic se mi v nem i lepe programuje.

Autor clanku je nepoucitelny socialni lamer, vysledkem je ze predevsim uskodi vsem tem, kteri se opravdu chteji naucit s BASHem ci jinym shellem (napr. nekoho muze zajimat Korn Shell - ksh). To je prvni fatalni chyba. Kdyz si kdokoli vygoogli bash scripting tutorial, dozvi se informace z prvni ruky, ktere budou strucnejsi, jasnejsi, presnejsi.

Jakou cenu ma psat podobne nekvalitni a socialne zkriplene (tzn. netechnicke) clanky? Co Vas k tomu prosim vede? Vase socialni demence?

"ostatně ani pythonní rozlišování řetězců a řetězců v unicode není příliš velká výhra"

Kde si na to prosimtě přišel? Python pracuje minimálně od tý doby co s nim pracuju já v unicode, převod mezi sadami se dělá přes něj, fce a metody pro práci s textem nemají jediný problém, tak kde ho hledáš ty?

Rekl bych, ze autor clanku narazi na zapis u"blafblaf" pro unicode retezce a "blafblaf" pro retezce.

Na tom neni nic špatnýho. V pythonu jde nastavit aby "blafblaf" řetězce byli třeba utf8 a s tim python pak pracuje. Takže se všechny převody budou konat přes utf8 nebo cokoli jiného. Rozhodně bych to neházel do jednoho pytle s ruby, které o unicode pomalu nemá šajnu.

Clanek o skriptovacich jazycich a opomiji uzasne SCSH?

na CVUTu se to uci.

ono se na školách učí ledacos, to podle toho jaké úchylky vyučující mají..

Scheme není funkcionální jazyk (ač se takto používá nejčastěji).

Ono dost vlastností původem z funkcionálních jazyků proniklo do mainstreamu (používání funkcí jako parametrů, generátory s líným vyhodnocováním, lambdy), aniž by se ty jazyky vzdaly Algol-like syntaxe, která je pro spoustu lidí zkrátka přehlednější. Nemluvě o infixových výrazech, které jsou jaksi člověku, který prošel klasickým školstvím, vryté do mysli.

K těm převzatým vlastnostem patří i třeba if, možnost rekurze a garbage collection - u prvních dvou už možná ani postfortranisti necítí, že jsou odjinud...

Rekurzi beru, ale if? Chápal bych IIF (ternární operátor v C a dalších jazycích).

Už chápu, v Algolu se if dal použít ve výrazech.

Jo, kdyby se na matfyzu ucilo SCSH, tak bychom mohli sloucit dve prednasky (Uvod do UNIXu a funkcionalni programovani) do jedne :-)

Ale ne - Programovani v SCSH s funkcionalnim programovanim ma jen velmi malo co spolecneho.

jak matfyzem?! scheme se pouziva k vyuce na vetsine vyznamnych univerzit, za vsechny napr. MIT, Pricenton, Oxford nebo Univerzita Palackeho. (tento oblibeny vtipek jsem si nemohl odpustit) ;-]

jinak ja radsi na blbinky pouzivam guile nez scsh ... protoze do guile jdou hezky dopisovat bindingy na dalsi veci....

Slysel jsem, ze take na VSE uci zaklady programovani ve Scheme.

Jo guile je take docela dobre. Ale na tradicni ulohy shellovych skriptu (prace se soubory, spousteni externich programu) mi prijde vhodnejsi scsh. Take bych rekl, ze je lepe dokumentovane.

na FI MU bere Haskell v rámci poviného Úvodu do funkcionálního programování

Však právě. Hned na začátku je ten správný okamžik, kdy má (budoucí) programátor získat dobré návyky. A Scheme a SICP jsou k tomu výbornou cestou, ne?

By mě zajímalo, čím je definován skriptovací jazyk? Že pro něj existuje interpreter, nebo že pro něj neexistuje kompilátor? Nebo že pro něj norma *zakazuje* vytvořit kompilátor? A co on fly kompilátory a kompilátory do byte kódu, ty se počítají kam?

Jinými slovy, ač myslím chápu, jak autor zamýšlel dělení jazyků, vést jako kritérium skriptovací/kompilovaný mi přijde lehce nešťastné - není to ani vlastnost jazyka...

No ono to deleni je obvykle spis interpretovane/kompilovane. Deleni podle ucelu (skriptovaci/...) je trochu stranou.

Konečně zase seriál, kterýmu budu rozumět :-) Díky za to.

Kde že roste ta spousta kvalitní dokumentace pro Ruby? Nad http://www.ruby-doc.org/core/ vždycky roním krvavé slzy, tak doufám, že autor doporučí něco lepšího :-)

PHP od Jirky Koska byla skvělá knížka, ale už máme jiné století

Pokud by jsme mel doporucit scriptovaci jazyk pro zacatecnika, tak AWK. Sice namitnete ze jej jiz nikdo nepouziva, ale presto si dovolim vyzvednout nektere vyhody:
- velmi jednoduchy
- velmi podobny C
- dostupny na kazdem UNIX systemu, existuje i port pro Windows ktery neni reba instalovat (jediny exe soubor)
- dobra podpora zpracovani textu (reguarni vyrazy)
- asociativni pole

Pokud clovek zvladne AWK, muze se presunout na PERL anebo jiny, modernejsi jazyk. Ac byl PERL navrzen jako "zabijak" AWK, jednodussi veci se v AWK pisi znatelne rychleji nez v PERLu; ostatne muzete vyzkouset a2p, "AWK to PERL", vysledny kod vysvetli ze nektere konstrucke jsou v AWK snadnejsi nez v PERLu. Na druhou stranu, AWK ma sve limity. Pokud lze ulohu prevest na "operace s textem", lze AWK pouzit. Vhodny take na rychle prototypovani. Nejcastejsi vyuziti asi jen jako "super grep", pripadne formatovac vystupu.

Mozna by bylo fajn porovnat naprogramovani nejake ulohy v ruznych skriptovacich jazycich. Ted frci hlavolan Eternity2, co treba uloha, ktera se zadanych souboru e2pieces.txt a (e2result.txt (stejny format jako e2hints.txt) spocita skore reseni (treba jako 460/480). Viz http://www.eternity2.net

Naprosto nechápu, v jaké sadistické náladě může někdo začátečníkovi doporučit awk.

Ale jestli to byl joke, tak sry....

Proc ne? awk je docela sympaticky jazyk a kod v nem je IMHO vyrazne citelnejsi (a semantika jednodussi) nez treba v perlu.

Programming Ruby jsem v minulosti take vynasel az do nebes, dokud jsem neobjevil The Ruby Way (posledni, myslim ze druhe vydani) a Ruby Cookbook / Rails Coobook (plus Rail Recipes). Silne doporucuji, tyto knihy dokumentuji jazyk Ruby a RoR opravdu velmi dobre

A Ruby on Rails uz je v dnesni dobe zdokumentovano vic nez dobre, mozna, ze i lip nez cele slavne PHP. A spousta novych titulu se chysta, staci mrknout na amazon.

To, jakym spusobem jsou Ruby a RoR dokumentovany IMHO vypovida o tom, ze se s nimi zacina docela dost pocitat plus uz nekolikrat jsem narazil na nazor, ze pry dost perlistu prechazi prave na ruby (asi se jim nechce cekat na Perl6 nebo co)

toz tak

'spusobem'.sub!(/^s/, 'z')

aj ked perl uz davno nie je hype, stale je zivy. zo vsetkych uvedenych jazykov je perl najuniverzalnejsi a existuje k nemu najviac rozsirujucich modulov.

pokial ide o pisanie scriptov pre administratorov, je urcite najvhodnejsi.
pokial ide o web aplikacie, zaciatocnikov odradi prilis vela moznosti, ktorou cestou sa pustit, ale urcite nezaostava technicky za ruby/python (pozri napr. catalyst).
pokial ide o objektovo-orientovane programovanie, perl nie je nativne cisto oop, naopak jeho vyhodou je, ze si mozete vybrat, ake oop vam vyhovuje. ak nechcete vyberat, pouzite Moose.

+1

Jazyk nevychazi z C ale z MNOHA jazyku. Jen manualova stranka uvadi 6 programovacich a jeden obycejny :)

V perlu se perfektne pisou one-liners. Usporna syntaxe neni na vrub citelnosti. (Samozrejme existuji ruzne souteze, jak co zapsat, ale ty nejsou jen pro perl.)

Perl obsahuje principy OOP, ackoliv asi ne na urovni, kterou by clovek zvykly na javu atd. hledal. Ale to neznamena ze v perlu nelze pouzit dedicnost, zapouzdrenost, pretezovani operatoru a funkci atd. Ve skutecnosti skoro kazde rozsireni perlu na CPAN je trida!

PERL je dobře čitelný? Pokud je člověk unixovým adminem (což je silná deformace), tak mu přijde čitelné lecos. Sice jsem v PERLu něco málo dělal, jistou poezii mu nelze upřít, jeho čitelnost je děsivá. Ten "tradiční" mrav, kdy kód vypadá, jako když někdo píše jen na číselném řádku klávesnice, a má zaeseklý šift, se dnes přece jen už nenosí.

Clanek jsem necetl, precetl jsem si jenom oblast shellu a ta me dostala:) Ze autor, asi nevi o power shellu ve Windows (dnes bezpecne nejlepsim shellu worldwide), to me ani tak neprekvapuje ... nicmene vyzdvihovat nebo se jen zminovat o KSH jako "jazyku" a jeste k tomu dnes nejak pouzitelnem, je fakt vysmech:) Lepsi skriptovaci jazyk byla i T602ka!:) (neni tam preklep:o)

lol

Bohuzel je dnes opravdu velmi popularni reagovat na neco co jste si ani neprecetl a jeste se k tomu tak hloupe priznat.

taky mě ani moc nepřekvapilo, že autor ztotožňuje shell ve windows s jednoduchým cmd, ovšem k tvrzením, že je něco nej- na světě jsem značně skeptický.

To je "security feature" ;-)

Take tu averzi k PHP nechapu. PHP je vyborne k tomu k cemu bylo urceno + obcas neco navic - da se v nem udelat i treba script pouzitelny pri administraci systemu. Ona je to dnes takova tak trochu moda :-) - myslim ta averze. Znam typky, kteri bastli v Jave a pripadaji si velice IN a tvrdi, ze delaji desne "robustni" zalezitosti... Ve skutecnosti jejich zamestnavatele za velke penize zakaznikum nuti pro reseni relativne jednoduchych uloh jejich neefektivni tučné vytvory, programovane lidmi, kteri temer ani netusi, jak funguje pocitac :-)) Podle toho to pak vypada...
Nerikam, ze PHP je nejaky zazrak a spasa, ale svuj ucel plni velmi dobre. Tim ucelem je jednoduse a do jiste miry univerzalne pouzitelny relativne mocny jazyk a interpreter.

m0n0wall a odvozene projekty pouzivaji PHP jako JEDINY skriptovaci jazyk, tedy jazyk pro psani systemovych skriptu. (http://m0n0.ch/wall/)

Mojim oblubenym skriptovacim jazykom je momentalne groovy. Ano, ano, vela ludi teraz pravdepodobne argumentuje, ze to potrebuje javu a z toho dovodu je pomaly. Mne to ale vobec nevadi :-) Ja groovy pokladam za najlepsi skriptovaci jazyk vo vesmire :-)

A pozor, právě vyšla první alphaverze Pythonu 3000.

Jazyk Groovy je jazyk se všemi rysy moderních skriptovacích jazyků. Běží v Java Virtual Machine a tím pádem lze naprosto hladce propojit s libovolnou javovskou knihovnou či frameworkem. Díky skvělé podpoře Unicodu v Javě netrpí neduhy s češtinou jako Ruby či Python. Pro připojení k databázi lze použít JDBC ovladače, které jsou všude k dispozici a hladce fungují.
Díky propojení s Javou má k dispozici tolik knihoven, že se o tom Ruby nebo Pythonu ani nesní.
Jistou nevýhodou je zatím o něco méně dokumentace a tutoriálů než u zavedenějších jazyků. Toto se ale den ode dne zlepšuje.

JRuby jsem nezkoušel, takže nevím, jestli je integrace s Javou opravdu tak hladká jako u Groovy, které bylo od začátku navrženo pro Javu.
Co mě odrazuje od JRuby či Jythonu: Ruby má jistě svou hierarchii objektů (standardních knihoven), stejně jako Java, ale tyto hierarchie jsou bezpochyby odlišné. Měl bych tedy použít daný objekt z Javy, nebo z Ruby? Měl bych soubor otvírat po javovsku, nebo po rubyovsku? Pokud jdou obě varianty, není to příliš dobře, protože jeden to může dělat tak a druhý onak a kód dělající totéž bude pak vypadat úplně odlišně.
A druhá věc: Vezmu-li klasický Ruby kód, půjde spustit v JRuby? A vrátí totéž? Bude tedy vracet tytéž špatné výsledky např. při vracení substringu ze stringu s diakritikou?

Hehehehehe, super, super, super, dalsi, co ma rad groovy :-) Pre tych, co o groovy este nepoculi, mam jedno varovanie: Pozor na groovy, v momente co sa s nim stretnete, si ho oblubite a stanete sa na nom zavisly :-)

emacs je napisany vo svojom specialnom dialekte lispu.

tcl velmi nepoznam, ale nejak sa mi to nezda. asi nemas nejaky zdroj, ze?