perl

Kicsit elkezdtem most foglalkozni vele (jelenlegi státusz: "0. szintű perl expert") és elborzaszt, hogy nincs egy trim(), egy isnumeric() vagy a megfelelőjük. Mindenki regexeket írogat aztán lehet bogarászni, hogy mit akart mondani a költő. (Nyilván ezeket be lehet tenni függvénybe, de miért nem része az alap perl-nek? cpan most nem játszik.)

Eddig (10+ év linux) simán megéltem bash -sal (+awk, sed, grep, stb.), ha tényleg nagyon kellett valami, akkor cli-s php.

Szóval érzem a késztetést, hogy meg kéne tanulni, de így eléggé elkedvetlenító.

( doc | 2013. 06. 26., sze – 13:54 )

a Perlnek eleg sajatsagos a "filozofiaja", valoszinuleg azert erzed annyira idegennek, mert meg nem hangolodtal ra
ha trim funkciot akarsz, nagyon egyszeruen irhatsz magadnak egyet (1 vagy 2 sorban, izlestol fuggoen :D), de nekem meg sosem hianyzott, pedig eleg sokat hasznalok Perlt (valoszinuleg pont ezert nincs defaultban a Perlben - kb. senkinek nem hianyzik :D)

"irhatsz magadnak egyet (1 vagy 2 sorban, izlestol fuggoen"

Na de minek, illetve miért nincs "gyárilag"?

"valoszinuleg pont ezert nincs defaultban a Perlben - kb. senkinek nem hianyzik"

Azért ez így nagyon meglep. Vagy a chop/chomp mindenre elég, akinek meg nem jó, az írogasson regexeket újra meg újra?

a miertre valaszoltam fent
sokezer sornyi Perl kod megirasa alatt egyszer sem jutott eszembe hogy megnezzem, letezik-e trim vagy isnumeric, es gyanitom nem en voltam az egyetlen
Valoszinuleg annyi a problema, hogy a php logikajat akarod rahuzni a Perl-re, aminek sok ertelme nincs. Lehet persze Perl-ben is "C-ben" programozni, meg "PHP-ban" is, de minek?

Ugyanilyen alapon lehetne írni isalnum isalpha isascii isblank iscntrl isdigit isgraph islower isprint ispunct isspace isupper isxdigit és (még vagy n+1 "alap" függvényt, lásd ctype.h) - kinek kinek mi a fontos. Mivel javarészt egy karakterosztálynak való megfelelést vizsgálják, így nem igazán van értelmes oka -szerintem- annak, hogy külön függvényként is elkészüljenek, de nyugodtan csinálhatsz egy ctype.pm modult, ami ezeket megvalósítja - ultrakényelmes Perl programfaragóknak.

De, van ertelme. Mert ezeket az ellenorzeseket a programozok 99%-a megirja maganak - valtozatos eredmennyel. Ha van egy referenciaimplementacio, akkor az azon fuggvenyek altal visszaadott ertekben mindig meg lehetne bizni.

De ha mar fuggveny nincs is, miert nincsenek olyan beepitett regex valtozok, amik az ezen fuggvenyeknek megfelelo regexeket tartalmazzak?

Mint ahogy fentebb irtak: lehet, hogy baromi konnyen implementalhatoak. Csak tudod, a szog es a kalapacs is viszonylag konnyen eloallithato cucc, megsem all neki senki ugy szogelni, hogy na akkor kell egy fanyel, egy vasdarab, egy rovidebb drotdarab, hevitsunk, kalapaljunk ki egy szoget, hegyezzuk meg, majd kalapaljuk be a falba. Inkabb vesznek egy szoget, meg vesznek kalapacsot, es az utobbival beverik az elobbit.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

marmint a HULYE programozok 99%-a, az ertelmesek hasznaljak a mar leimplementalt fuggvenyeket :)

a kalapacsos peldad meg MAJDNEM jo: jelenleg ugyanis arrol vitazunk, hogy ott a kalapacs a polcon csak le kene venni, ehelyett az eCCeri juzer nekiall jajveszekelni hogy "jajj nincs kalapacs, jajj nincs kalapacs". aztan mikor kozoljuk hogy DE VAN, ott a polcon csak le kell venni, akkor meg jon az hogy "de en nem akarom a polcrol levenni, jajj nincs kalapacs, jajj nincs kalapacs" :D

NINCS. Ha megirod, akkor lesz. Illetve nyilvan CPAN modulbol van minden, de azert ezek alapvetoen nem olyan fuggvenyek, amiket kulso modulbol kellene hasznalni. Es nem csak a PHP-nak, minden interpreternek vagy beepitett, vagy az stdlibben levo fuggvenyei ezek. A ctype.h -bol gyakorlatilag egy mozdulattal generalhatoak (na jo, a trim nem).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem jott at. Persze, CPAN modulban van, magaban az alap standard konyvtarban NINCS. Nem mindig van lehetoseged a celrendszerre CPAN modult tenni, mert peldaul nincs make parancs, vagy csak siman jogod nincs hozza. Ezek a fuggvenyek annyira alapvetok, hogy nem kellene olyan korlatok koze szoritani a hasznalatukat, hogy peldaul kell jogodnak lenni CPAN modult telepiteni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Eegen... de csak meg kellett írnod. :)

Különben értem én a koncepciót, csak nehezítésnek tartom, mert ha programot írok, akkor egy bizonyos problémát szeretnék megoldani a meglévő eszközökkel viszonylag hamar és először nem összelegózni szeretném az eszközt, amivel majd megoldom a problémát. Kicsit IKEA fíling.

Egyébként jogos a kérdés, hogy miért sírok és ki kényszerít, hogy használjam. De minap volt egy beszélgetésem, ami elég hamar egy kötetlen felvételi interjúvá vált és az adott cégnél belépő követelmény az erős perl tudás, mert hogy az üzemeltetés arra épít. Amikor rákérdeztem, hogy vajon naponta írnak-e olyan bonyolultságú üzemeltető toolokat, amiket nem lehet bash-ban (+ az egyéb toolok) megcsinálni, vagy csak valaki rá van tekeredve a perl-re és ezért mindenkinek azzal kell még kávét is főznie, akkor bizonytalan hümmögés volt a válasz.

Nincs mindenütt bash - se. Ha valahol van egy jelentősebb Perl/Cobol/Fortran/BASIC/akármi kódbázis, akkor természetes, hogy abban kell otthonosan mozognod, hiszen használni és csiszolni kell majd azokat.
Perl-ben ezt pl. meg kell írni, és gondolom, azért nincs "gyárilag" ilyen, mert ennyi megírni magadnak :-D A CPAN-on viszont van egy nagy rakás olyan Perl modul, ami tényleg komolyabb feladatokhoz sitty-sutty ad eszközt a kezedbe.

( Cajga | 2013. 06. 26., sze – 14:26 )

[off]
Szereny velemenyem: Perl egy iszonyatosan jo nyelv azoknak, akik minden nap abban programoznak vagy akinek kiveteles memoriajuk van. En irtam perlben egy kb 3 ezer soros programot (amolyan configuracio management szeruseg) es 1 ev utan foggalmam sem volt, hogy mit is csinalok benne valojaban (persze ez fokent az en hibam volt a sok jonak hitt rovidites es szinte 0 comment miatt).
Aztan ugy hozta a sors, hogy megismerkedtem a python-nal. Azota kizarolag pythonban irok mindent (persze csupa sysadmin-os max par ezer soros cucc) ;)
[on]

Sok sikert.

( anr | 2013. 06. 26., sze – 16:21 )

a perl az egyetlen programnyelv, amit konnyebb irni, mint olvasni

--
Live free, or I f'ing kill you.

( dap | 2013. 06. 26., sze – 22:48 )

[off]
Peeerl? Eszedbe ne jusson. Rendszergazdának ruby esetleg python való, nem utolsó sorban azért, mert a modern-népszerű SCM eszközök is ezekre épülnek (ld. Puppet, Chef, Bcfg2, stb), ebben lehet őket bővíteni. A python gyorsabb, de az eldobható scripteknek jobb a ruby, kevesebb kötöttség és a onelinerek is frankók.

Kellett valaki aki elkezdi, na. ;)
[/off]

I beg to differ...

Nem 1x futottam bele, hogy megírtam valami rendszer admin cuccot 1 nyelven, majd amikor portolni akartam azt egy másik rendszer/OS alá koppantam a padlón, mert ott vagy függőségi problémákba ütköztem, vagy szimplán nem volt elérhető az adott környezet a rendszeren (és most ne csak Linux rendszerekre gondolj: AIX, illetve mostanság futottam ugyan ebbe bele Solaris és HP-UX alatt is). És a vicc, hogy még a shell scriptekre se lehet 100%-osan építeni, mert ott is a különböző rendszereken elérhető shellek be tudnak kavarni (pedig hányszor áldottam volna az eget, ha ksh alatt (nem ksh93) valaki implementált volna egy NORMÁLIS tömb kezelést).
És most lehet röhögni fogsz, de a perl viszont egy olyan környezet ami mindegyiken ott van, ergo simán (vagy nagyon kevés átalakítással) lehet portolni a megírt toolt más rendszer alá, szemben bármi mással. Ehhez vedd hozzá a tömérdeknyi modult és már tisztább lesz miért is annyira szimpatikusabb ez sok esetben.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A rubynak (core+stdlib) elég szerények az igényei, az rvm.io pedig robotpilótaként menedzseli a fordítást és a telepítést, valószínűleg minden modern UNIX-on teljes értékűen működik. Másrészt, a rubyban írt puppet is multiplatform, többek közt AIX, HP-UX és Solaris támogatással [1], gondolom kipróbálták. A tömérdek modul egyébként megvan minden nagy nyelvben.

Biztos van az a helyzet amikor a perl kényelmesebb, de alapesetben én inkább előre tekintenék..

Lefuttattam egy 

find -name "*.p[lm]" | xargs wc -l

-t a project mappámban, 12.660 sor perl-t írtam, de az idő sem igazán szépítette meg a nyelvet.

Ohm, van amikor hozott anyagbol kell dolgozni, pl. hibakeresesnel nincs ido es lehetoseg RVM-mel Ruby-t forditani.

Szerintem is hasznos tudas a Perl tudas, vigyazni kell ra, keveset hasznalni, sokat olvasni rola, nehogy elkopjon.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Az 1 dolog, hogy fel lehet rakni, és lehet használni, de pont az olyan rendszereken szokott az kijönni, hogy ha olyan program miatt szívsz ami nem része az támogatott csomagoknak (avagy nem a disztribútor csomagolta) akkor nincs más, csak hogy te debugolod/oldod meg a problémát (akkor is ha csak 1-2 programkód hiba van, meg akkor is ha valami library inkompatibilitás). Pont ez miatt nem szeretik annyira a 3rd party dolgokat ezeken a rendszereken, mert amíg működik addig mindenki örül, amikor meg nem, akkor meg pénzért is nehezen találsz bárkit aki tényleg olyan szinten bele tudna túrni minden lehetséges hibaforrásba, hogy meg is tudná oldani a problémát.
Ezzel szemben a perl része (tudtommal - citation needed) minden alap rendszernek, ergo kérhetsz rá hivatalos támogatást, ha valami olyan hibába futnál bele, ami nem a perl kód hibája (hanem az akörül lévő környezeté), és ha kell akkor az OS fejlesztői kezdik el neked túrni, hogy most akkor wattafák van..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..