Ma 20 éves a Perl

Hír

1987. december 18-án Larry Wall kibocsátotta Perl 1-et. Ez azt jelenti, hogy ma ünnepeljük a Perl 20. születésnapját. Azóta e nyelv számos kiadást látott (1988: 2., 1989: 3., 1991: 4., 1994: 5.), jelenleg pedig az 5.8.8-as stabil és az 5.9.5-ös fejlesztői verziónál tart.

Az első verzió még "csupán" a sed és az awk egyfajta továbbfejlesztése volt. Ma a Perl-nek majd' száz bináris portja (disztribúciója) létezik. Használható többek között szöveges és bináris adatfájlok feldolgozására, adatbázis-programozásra; HTML, XML feldolgozásra; támogatja a Unicode-ot, a procedurális, az objektum-orientált és a funkcionális programozási paradigmákat; s e pillanatban 12 718 db harmadik fél által fejlesztett modullal rendelkezik (elérhetők a CPAN-on) különféle általános és egyedi programozási feladatok megoldására.

Szép eredmény, boldog születésnapot, Perl!

( hory v | 2007. 12. 18., k – 14:17 )

Utalom... Gany, mint allat. Tenylegesen _minden_ randa hack benne: a thread-ek, az OO, minden.

Atgondolatlan tervezes (pl. hash szintaktikailag nagyon melyen beepitett tipus - ez a gyonyoru OOs java es .net collection-ok vilagaban nevetseges), es az osszes modern feature utolagos belehackelese (de randan am), ronda, olvashatatlan szintakszis. Es akkor a context-ekrol nem is beszeltem: 2007-et irunk, konyorgom, ennel meg a C cast-jai is jocskan kulturaltabbak. Meg ugye a mindent tobbfelekeppen lehet megcsinalni. Ugyanazt az if-et 5(!!!) felekeppen lehet leirni!

Mindent osszevetve meg a perl6 is keves lesz az uj nyelvek mellett (pl. python elegge hasonlo, de normalisan meg van csinalva).

A perl halalat pont ez fogja okozni. Ugyanis nagyon keves ember fog a perl mellett donteni, amikor programozni tanul - nyilvan a python, ruby es tsai jocskan vonzobbak, ertheto (meg a fenti) okokbol. Ez viszont azt jelenti, hogy nincs utanpotlasa a platformnak, vagyis szep lassan kihal. Ez nem perl-specifikus - minden platform/nyelv igy vegzi valamikor. Evolucio.

CPAN... pont olyan, mint maga a nyelv. Rohadt sokminden van meg ott, de a modulok telepitese gany. Valahogy bedobja a fajlrendszerbe, oszt csokolom. Te meg vakarhatod a fejed, hogy mi honnan mikor kerult hova. Mindezt nagyjabol meg ki lehet talalgatni, de tudtommal arra pl. egyaltalan nincs mod, hogy megmondd, hogy melyik modul kerult oda a CPAN-bol es melyik mashonnan (pl. disztrod csomagjabol) -- van olyan parancs, ami kilistazza az installalt modulokat, de ezt a kulonbsegtetelt nem teszi meg.

Ehhez kepest mennyivel jobban meg van csinalva a gem util, amivel Ruby modulokat lehet felpakolgatni! A gem egy teljesen funckionalis sub-package manager, egy csomagkezelotol elvarhato introspeckios kepessegekkel. Es mivel a Ruby kozossegben abszolut sztenderdde valt h minden release-t kiadnak gem formatumban is, egy Ruby program installalasa pofonegyszeruen, a gem install foo parancssal tortenik, es meg fajnia se kell az ember fejenek a fajlrendszer osszeganyolodasa felol.

Altalaban perl-nel erdemes eldonteni, hogy a distro vagy a cpan installeret hasznalod, ugyanis a verzio utkozesek miatt a ketto parhuzamos hasznalata nem ajanlott. Debian eseteben pl. a CPAN hasznalata a recommended, persze ekkor a szoftverek listajat veglegesiteni kell, mert ha barmi valami csomagolt CPAN-os csomira fugg, akkor megint ugyan ott vagyunk.

Ne használd! Nem kötelező...
Vannak szép számmal, akik szívesen használják, mert pillanatok alatt megoldást lehet benne találni egy adott problémára.
"gyonyoru OOs java es .net collection-ok vilagaban": Vigyázat, ez hibrid nyelv (lásd C++, de még inkább Lisp)! Nem lehet elvárni tőle, hogy illeszkedjen az OO gondolatvilághoz, típusokhoz, szintakszishoz, stb.
"mindent tobbfelekeppen lehet megcsinalni": Humán interfésze van, ez alatt azt értem, hogy feltűnően hasonlít az emberi nyelvekhez a gondolkodásmódja sok helyen; az emberi nyelveken is igen sokféleképp ki lehet fejezni valamit, ha nem így lenne, nem létezne az irodalom (ez utóbbit lehet, hogy nagy betűvel kezdhetném). Így mindenki úgy fejezi ki benne magát, ahogy épp a gondolkodásához igazodik. Ez valakinek előny, valakinek meg hátrány, mindenki döntse el maga.

+1.. Most kezdtem el én is eléggé használni, mert a sok modul miatt elég rendesen meg tudom könnyíteni a dolgomat, és nagyon sokfajta feladatot meg tudok vele oldani.. Az OO része mondjuk nekem is kicsit nyögve-nyelősen ment de ahogy néztem ott sincs semmiféle lehetetlen, és tetszik, hogy ha esetleg nem tudok valami parancsot, akkor egy másik nyelvből ismertet beírva eddig 5ből 4x működött az adott parancs ( tehát itt is átvették ), így amikor nem volt netem akkor se kelett kétségbeesnem, hogy mi lehet az ami nekem kell, hanem 1x kipróbáltam az adott funkcióra érvényes más nyelvekben lévő parancsot, majd ha az se ment mentem perldoc-ra :))

Azt mondjuk aláírom, hogy komolyabb programot valószínű nem ebben kell fejleszteni, de ha az embernek a bash script által nyújtott lehetőségek már kevésnek bizonyúlnak, akkor ez tökéletes alternatíva tud lenni. És lényegében nekem pontosan erre van szükségem.
____________________________________
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: -"Üllj le és kuss legyen!"..

Humán interfésze van, ez alatt azt értem, hogy feltűnően hasonlít az emberi nyelvekhez a gondolkodásmódja sok helyen; az emberi nyelveken is igen sokféleképp ki lehet fejezni valamit, ha nem így lenne, nem létezne az irodalom

Akinek irhatnekja van, irjon az elet es irodalomnak. Az IT mernoki szakma, es mint ilyen, nincs benne helye olyan szintu pongyolasagnak, amit az emberi nyelvek megengednek. Ez a masik, ami borzalmas benne: ha ertelmetlen kifejezest irsz, azt is megprobalja vegrehajtani, akkor is, ha ezaltal valami elore teljeseggel nem tervezett dolgot hajt vegre.

A programnyelv/platform ne akarjon okosabb lenni a programozonal. Nem lesz az ugyanis. Messze, nagyon messze vagyunk meg attol. Hulyeseget meg ne csinaljon, ha tudja, hogy valami hibas...

természetesen igazad van, a szerver oprendszerek között is szerintem végül csak a Windows szerverek fognak maradni, mert a többi annyira primitív meg hülye, hogy még grafikus felület sincs (!!!) rajtuk.
Ezt alá tudom támasztani például statisztikákkal, hogy a '80-as években a linuxnak a szerver oprendszerek körében 0% volt a penetrációja, ez az arány azóta biztos csak romolhatott. 

int getRandomNumber() {
return 4; //szabályos kockadobással választva. garantáltan véletlenszerű.
} //xkcd

khm....
Windows 2008 Server Core - Command prompt. Semmi más. Ha véletlenül becsukja az egy sugaru rendszergazdi akkor, hiába kaparászik a Start Menu után - az nincs.

:-D

forras: Microsoft Technet

---------------------------
Az információ egysége a bit, nagyobb egysége a megabit, kisebb egysége a mikrobit.

"Gany, mint allat. Tenylegesen _minden_ randa hack benne: a thread-ek, az OO, minden."

Az OO es a threadek tenyleg picit hack, de:
- megverte Erlangot parallel processingben (nemreg volt news)
- a threadelt resz nem a fo felhasznalasi irany
- Az OO jol hasznalhato annak ellenere hogy hozza lett csapva dolgokhoz.

"Es akkor a context-ekrol nem is beszeltem"

Izlesbeli kulonbseg, nekem tetszik a sigil variance, neked nem. Nem kotelezo hasznalni.

"Ugyanazt az if-et 5(!!!) felekeppen lehet leirni!"

Feature. There is more than one way to do it.

"A perl halalat pont ez fogja okozni. Ugyanis nagyon keves ember fog a perl mellett donteni, amikor programozni tanul - nyilvan a python, ruby es tsai jocskan vonzobbak, ertheto (meg a fenti) okokbol."

Egyreszt nem nyilvanvalo, masreszt az utobbi harom evben harom szamjeggyel nott a Perl-es allasajanlatok szama. En pl jol megelek Perlbol, koszonom szepen. Egyebkent meg ha halott nyelv is lenne, a COBOL mar evek ota az, es tenyleg egy ratyi nyelv, megis nagyon jol lehet keresni peldaul COBOL programozokent es meg mindig novekvo igeny van rajuk ha jol tudom.

"Mindent osszevetve meg a perl6 is keves lesz az uj nyelvek mellett (pl. python elegge hasonlo, de normalisan meg van csinalva)."

Mint minor Perl 6 fejleszto, engedd meg hogy kijavitsalak. Tele van ujdonsaggal es hasznalhato dolgokkal a Perl 6 aminek a kozelebe se er semmi a piacon. Haskell talan reszben.

A legnagyobb problema az az, hogy sokan C-t akarnak programozni Perlben. Összehasonlitaskeppen a 7 legfontosabb Lisp funkciobol 6-ot tud a Perl. A C egyet. Eszmeletlen sok a rossz minosegu Perl tanulasi segedlet...

Par Perl 5 elony:

- stringkezelesben verhetetlen
- interpretalt nyelvkent kiemelkedoen gyors
- CPAN. 'Nuff said.
- konzisztens core funkciok es konvenciok, vilagos namespace szeparacio.
- no whitespace nazism
- nagyon jo biztonsagi track record.
- A modularitasnak es a tomor kodszerkezetnek koszonhetoen egy kompetens Perl fejleszto komperative nagyon gyorsan tud minosegi kodot produkalni, mondjuk egy nem interpretalt nyelvhez kepest mint a C. A teljesitmeny kulonbseg nem feltetlenul nagy, foleg ha XS modulokat hasznalsz, abban az esetben teljesen elhanyagolhato lehet.
- Larry egy zseni ;)

Konkluzio: meg kell ismerni a Perlt hogy igazan velemenyt tudjal rola mondani.

Sokan "baba" Perlt tudnak csak, mert nem kenyszerit ra a nyelv szigoruan vett ertelemben hogy mindent megtanuljal egy one linerhez. De nem jelenti ez azt, hogy nincs tobb potencial a nyelvben.

Egyebkent sorry a mixed english es magyarert, faradt vagyok es FLFW (First Language, First Write) utemezest hasznaltam.

Idézet:
Egyreszt nem nyilvanvalo, masreszt az utobbi harom evben harom szamjeggyel nott a Perl-es allasajanlatok szama. En pl jol megelek Perlbol, koszonom szepen. Egyebkent meg ha halott nyelv is lenne, a COBOL mar evek ota az, es tenyleg egy ratyi nyelv, megis nagyon jol lehet keresni peldaul COBOL programozokent es meg mindig novekvo igeny van rajuk ha jol tudom.

Érdekes dolog ez. Két okból növekedik egy nyelvhez az álláshirdetések száma: ha nő a népszerűsége, vagy ha kihal.

a threadelt resz nem a fo felhasznalasi irany

Ahha. Vegulis nem jonnek a tobbmagos procik, nincs lassan a karorakban is parhuzamos vegrehajtas, ugye? Ez az egesz csak valami rossz remalom lehet.

;)

Az OO jol hasznalhato annak ellenere hogy hozza lett csapva dolgokhoz.

Nem. A OOPerl egesz egyszeruen nevetseges, hasznalata fajdalmas. Minden sornal leri rola, hogy randa hekk az egesz.

Rakj egymas melle egy perl OO forraskodot es mondjuk egy java OO forraskodot, ami egy legalabb 3 szintu hierarchikus szerkezetet valosit meg! Namost szerinted melyik attekinthetobb, erthetobb, konnyebben modosithatobb? Egyertelmu a java. De mondhatok nyugodtan c#-ot is (ami gyakorlatilag egy MS-itett es erosen javitott java).

Ha ezt figyelembe veszed, akkor szerinted ki fog OO-t csinalni perl-ben? Kb. senki. Marpedig errefele tendalunk az utobbi evtizedben. Nem ok nelkul.

Feature. There is more than one way to do it.

Ettol maszok falra :)
A gond ezzel az, hogy _neked_ valoban kenyelmesebb, de amint team-munka van, maris ott tartunk, hogy mindenki masmilyen szerkezetet hasznal, ergo _mindenkinek_ nagyon tisztaban kell lennie az _osszes_ szintaktikai edesitoszerrel (mert tipikusan gyakran kell egymas kodjaban debugolni/hibat javitani/modositani).
Es iszonyuuuu sok van beloluk! Ez nagyon elbonyolitja a tanulast es a csapatmunkat (marha ossze tud szedni az ember egy csapatnyi perl programozot egyaltalan - keress ra a jobserve.com -on pl., hogy mennyi ilyen-olyan programozot keresnek es lass csodat).

Mint minor Perl 6 fejleszto, engedd meg hogy kijavitsalak. Tele van ujdonsaggal es hasznalhato dolgokkal a Perl 6 aminek a kozelebe se er semmi a piacon. Haskell talan reszben.

Ezt a tevhitet is lattam mar perszor.
Egy cegben, amiben folyton cserelodnek az emberek (atlag developer max. 4-5 evente allast valtoztat), minel minimalisabbra akarjak szoritani a tanulassal toltott idot. Ez kizarolag szabvanyositassal megy. Idealis esetben felvesznek valakit az utcarol, es megmondjak, hogy az X-be implementaljon egy uj Y feature-t, es 1-2 oran belul mar produktiv. Ez csak akkor lehetseges, ha pl. java eseten eclipse+cvs+valamilyen framework, pl. spring+ant+... -ot hasznalnak. Es pontosan ez az oka, hogy ezek a platformok ennyire eloretortek.
Es pontosan ez az, ami miatt a perl6 hiaba tartalmaz komolyan high-end ujitasokat, nem fogja tudni megtorni a java/c#/... eloretoreset. Az, amire tenyleg szukseg lenne, hianyzik belole: a csapatmunka fokuszba kerulese. Ha megnezed pl. a CPAN-t is, hany modul van, amit tobben fejlesztenek? Tipikusan maganyos gerillak osztanak meg a vilaggal egy-egy modult. De ez nem az, amerre a vilag tart.

A legnagyobb problema az az, hogy sokan C-t akarnak programozni Perlben. Összehasonlitaskeppen a 7 legfontosabb Lisp funkciobol 6-ot tud a Perl. A C egyet. Eszmeletlen sok a rossz minosegu Perl tanulasi segedlet...

Ebben egyetertunk. Hadd fuzzem hozza viszont, hogy ha megfigyeled, az _osszes_ "nagy" nyelv a c/c++ csaladba tartozik: c, c++, java, c#. Ha tudsz az egyikben, a masik mar relative egyszeru (a java-c# atmenet pl. szinte nulla ido). Az emberek ezt szoktak meg. Ha most jon a perl egy teljesen masik gondolkodasmoddal (ami BTW a perl-rol valo valtast is igen nehezze teszi), szerintem mekkora eselye lesz a fenti negy nagyagyu elleneben?

Egy nyelv elterjedesehez rengeteg minden kell: a meglevo developerek megnyerese, egy jo platform, jo konyvtartamogatas, stb, stb... Az uj nyelv+platformok tobbsege ezek _mindegyikevel_ rendelkezik. Vagyis ha csak 1 hianyzik egy nyelv+platformnal, az rovid vagy hosszu tavon, de halalra van itelve.

- stringkezelesben verhetetlen

Az IO a szoftver <<5%-at teszi ki. Ha ennel tobb, akkor valamit nagyon elszurtal.
Belsoleg meg objektumokat szokas passzolgatni, nem stringeket. Gyorsabb es merfoldekkel kulturaltabb, mert rakenyszerit egy szerkezetet az adatra, ezaltal elkerulve, hogy minden fuggvenyben tenylegesen interpretalni kelljen az argumentumokat.
Amit irsz, csak egy ujabb perl-worst-practice.

- interpretalt nyelvkent kiemelkedoen gyors

C, C++, JAVA, .NET. Mi a kozos? Az, hogy mindegyik kepes gepi kodra forditani.
Az interpreter a qbasic.exe -ben meg OK, 2007-ben egyszeruen nevetseges.

- CPAN. 'Nuff said.

Ezt mas mar kifejtette egy masik hozzaszolasban: tenyleg jo, de rengeteg szivas van az installokkal. Tipikusan gcc-zni kell, path-ok nem megfeleloek, stb... Igazabol ilyen szinten minden nyelvnek van CPAN-je, csak google-nek, sourceforge-nak, freshmeat-nek, apache.org-nak, ... hivjak.

- konzisztens core funkciok es konvenciok, vilagos namespace szeparacio.
- no whitespace nazism
- nagyon jo biztonsagi track record.

Ezek alapveto featurek akarmelyik nyelvben.

- A modularitasnak es a tomor kodszerkezetnek koszonhetoen egy kompetens Perl fejleszto komperative nagyon gyorsan tud minosegi kodot produkalni, mondjuk egy nem interpretalt nyelvhez kepest mint a C. A teljesitmeny kulonbseg nem feltetlenul nagy, foleg ha XS modulokat hasznalsz, abban az esetben teljesen elhanyagolhato lehet.

Ha xs-t hasznalsz, akkor mar C-ben is tudnod kell.
A produktivitas valoban problema, de abban meg a python es a ruby ver ra csunyan a perl-re. Nagy rendszereknel meg a c/c++/java/... jobb nala.

Konkluzio: meg kell ismerni a Perlt hogy igazan velemenyt tudjal rola mondani.

Ez tortent. Csak epp a basic, x86 ass, pascal, c, c++, java, .net, shell, python utan. Ezert a fenti velemeny.

Sokan "baba" Perlt tudnak csak, mert nem kenyszerit ra a nyelv szigoruan vett ertelemben hogy mindent megtanuljal egy one linerhez. De nem jelenti ez azt, hogy nincs tobb potencial a nyelvben.

Epp ez a bajom. A perl bash-helyettesitonek egesz jo, ahogy valaki megjegyezte, de a c/c++,java,c# -el nem veheti fel a versenyt. Meg a python es a ruby is megveri, igaz, nem teljesitmenyben, de produktivitasban es atlathatosagban/tanulhatosagban igen.

Ahha. Vegulis nem jonnek a tobbmagos procik, nincs lassan a karorakban is parhuzamos vegrehajtas, ugye? Ez az egesz csak valami rossz remalom lehet.

5.8 ota nincs igazan baj a threadekkel. Az meg 5 eves release.

Nem. A OOPerl egesz egyszeruen nevetseges, hasznalata fajdalmas. Minden sornal leri rola, hogy randa hekk az egesz.

Lehet hogy ra lett hackelve az interface-re, de van sok elonye. Egyreszt nem rejti el a juzer elol hogyan lesz valami OO. Egyebkent meg nem borzalmas egyaltalan az OO, konkretan a kod 90%-a amit irtam az utobbi evben OOPerl volt, meghozza a bonyolultabb strukturaju oroklodessel, stb.

Ettol maszok falra :)
A gond ezzel az, hogy _neked_ valoban kenyelmesebb, de amint team-munka van, maris ott tartunk, hogy mindenki masmilyen szerkezetet hasznal, ergo _mindenkinek_ nagyon tisztaban kell lennie az _osszes_ szintaktikai edesitoszerrel (mert tipikusan gyakran kell egymas kodjaban debugolni/hibat javitani/modositani).
Es iszonyuuuu sok van beloluk! Ez nagyon elbonyolitja a tanulast es a csapatmunkat (marha ossze tud szedni az ember egy csapatnyi perl programozot egyaltalan - keress ra a jobserve.com -on pl., hogy mennyi ilyen-olyan programozot keresnek es lass csodat).

Konkretan csapatban fejlesztek Perlt, szoval hadd osszak meg egy kis insider infot errol. Nincs problemank mas kodjat elolvasni. Persze ismerni kell a nyelvet, de egyreszt vannak konvenciok, mint minden mas nyelvet hasznalo programozoi kornyezetben, masreszt meg amit lehet tobb felekeppen, az nagyjabol egy semara megy. Ismerni kell az alapotletet hozza es tudod hasznalni mashol is.

Ezt a tevhitet is lattam mar perszor.
Egy cegben, amiben folyton cserelodnek az emberek (atlag developer max. 4-5 evente allast valtoztat), minel minimalisabbra akarjak szoritani a tanulassal toltott idot. Ez kizarolag szabvanyositassal megy. Idealis esetben felvesznek valakit az utcarol, es megmondjak, hogy az X-be implementaljon egy uj Y feature-t, es 1-2 oran belul mar produktiv. Ez csak akkor lehetseges, ha pl. java eseten eclipse+cvs+valamilyen framework, pl. spring+ant+... -ot hasznalnak. Es pontosan ez az oka, hogy ezek a platformok ennyire eloretortek.
Es pontosan ez az, ami miatt a perl6 hiaba tartalmaz komolyan high-end ujitasokat, nem fogja tudni megtorni a java/c#/... eloretoreset. Az, amire tenyleg szukseg lenne, hianyzik belole: a csapatmunka fokuszba kerulese. Ha megnezed pl. a CPAN-t is, hany modul van, amit tobben fejlesztenek? Tipikusan maganyos gerillak osztanak meg a vilaggal egy-egy modult. De ez nem az, amerre a vilag tart.

Ezt ugy hivjak hogy kod ganyolas. Ha ilyen szakemberekben merjuk a tudast akkor en annyi munkat vegzek el mint 20 programozo adott ido alatt, kevesebb buggal es jobb teljesitmennyel. Egyreszt a coding standards az egy adott dolog, de ha fel tudsz venni az utcarol egy szakembert es 1-2 oran belul le tudod ultetni kodolni, akkor az csak problemakat szul. Egy fejlesztot nem tudsz vakuumban tartani, meg akkor sem ha a kodod 100% enkapszulalt. Mert a programozot azert fizetik hogy gondolkozzon, amikor nem kell gondolkozni a programozashoz, az nem forraskod irasnak hanem adatbevitelnek hivjak. (Zarojelben, cvs-el ne rohogtess koszi.)

Egyreszt Perl6-ban öröm programozni, mert van egy DWIM-es feelingje, ami bonyolult dolgok leprogramozása esetén is megmarad, masreszt meg rendelkezik egy csomo olyan feature-el ami miatt tipikusan jol hasznalhato lesz ceges, csapatmunka szintu kornyezetben, de inkabb tajekozodj a nyelvrol mint en irjak itt feature listat...

A CPAN tenyleg maganyos melo, azert maganyos mert egyszemelyes project 500x tobb van a vilagban mint 2+ szemelyes. A CPAN-ra bárki feltöltheti a modulját, nem kötik semmihez a megosztás lehetőségét. Máshol csak a top 50 komponenst látod mondjuk.

Az IO a szoftver <<5%-at teszi ki. Ha ennel tobb, akkor valamit nagyon elszurtal.
Belsoleg meg objektumokat szokas passzolgatni, nem stringeket. Gyorsabb es merfoldekkel kulturaltabb, mert rakenyszerit egy szerkezetet az adatra, ezaltal elkerulve, hogy minden fuggvenyben tenylegesen interpretalni kelljen az argumentumokat.
Amit irsz, csak egy ujabb perl-worst-practice.

Marmint ugyerted hogy azokban a tipikus alkalmazasokban amire te szoktad hasznalni. Egyebkent nem veletlenul van bioperl, DNS (DNA) analizisre, meg egy rakas parser Perl-ben. Mert jo a programozonak (konnyen irhato es powerful) es jo a gepnek (gyors). A belso adatpasszolgatasrol pedig csak annyit, hogy mindennek megvan a helye. Nyilvan egy prevalidalt adatstrukturat jobban megeri bizonyos helyeken hasznalni, de a helper fuggvenyeknel meg nem erdemes bonyolultabb dolgokkal veszodni.

C, C++, JAVA, .NET. Mi a kozos? Az, hogy mindegyik kepes gepi kodra forditani.
Az interpreter a qbasic.exe -ben meg OK, 2007-ben egyszeruen nevetseges.

Nyilván jó dolog, ha tud valaki bytecode-ra fordítani, Perl 6 majd ezt is tudni fogja, viszont közel sem olyan fontos mint gondolnád.

Ezek alapveto featurek akarmelyik nyelvben.

Viszont kapasbol PHP, Python es a Ruby megbukik rajtuk.

Ha xs-t hasznalsz, akkor mar C-ben is tudnod kell.
A produktivitas valoban problema, de abban meg a python es a ruby ver ra csunyan a perl-re. Nagy rendszereknel meg a c/c++/java/... jobb nala.

Ahhoz hogy "use DBI;" meg nem kell megtanulni C-ben, de C sebesseggel megy.
Pont CPAN miatt nem gyorsabb egyaltalan Python/Ruby kodot irni. Nagy rendszerben is lehet jo Perl kodot irni. 100K-1M LOC folottire gondolok.

Ez tortent. Csak epp a basic, x86 ass, pascal, c, c++, java, .net, shell, python utan. Ezert a fenti velemeny.

Inkabb ugy erzem, hogy valamilyen okbol "you have an axe to grind against Perl".

5.8 ota nincs igazan baj a threadekkel. Az meg 5 eves release.

OK. Akkor most rabokok egy random cpan modulra, es mond meg, hogy thread-safe-e. Ugye nem megy?
A java es a c# rogton brutal thread-supportal kerult ki, igy gyakorlatilag minden thread-safe benne, vagy ha nem, akkor hatalmas fekete betukkel ki van irva a doksijaba.

Lehet hogy ra lett hackelve az interface-re, de van sok elonye. Egyreszt nem rejti el a juzer elol hogyan lesz valami OO.

Az OOperl ronda es fajdalmas. Ha ezt nem vagy kepes belatni, akkor nincs mirol vitazni. Mondom, rakj egymas melle egy java es egy ooperl kodot, es meglatod. Tanulhatosag, atlathatosag (ami a legfontosabb a fejlesztesben) kb. egy nagysagrenddel jobb a java-nal.

Nincs problemank mas kodjat elolvasni. Persze ismerni kell a nyelvet, de egyreszt vannak konvenciok

Nektek. Akkor most rakj ossze nullarol egy ooperl es egy java csapatot. Szerinted hanyszor lassabban csiszolodik ossze egy ooperl csapat?
Es persze, vannak ajanlasok, de akkor megint ott tartunk, hogy ha egymasra raksz egy java konyvet meg egy perl+ooperl+perl best practices konyvet, akkor az ooperl 3x vastagabb - nem ok nelkul. Feleslegesen bonyolult.

Ezt ugy hivjak hogy kod ganyolas. Ha ilyen szakemberekben merjuk a tudast akkor en annyi munkat vegzek el mint 20 programozo adott ido alatt, kevesebb buggal es jobb teljesitmennyel.

Nem. Ezt ugy hivjak, hogy ELET. Nagy rendszer, cserelodo programozok, 5-6 fos csapat pontosan igy muxik. Ha nem standard dolgokat hasznalnak, hanem nekiallni hazilag osszekotyvasztani mindent, egeszen pontosan ez fog tortenni. Nem azert, mert lamak a programozok, hanem mert 5-6 fos csapatban mar egy nagysagrenddel tobbet szamit a szervezes es a csapatmunka hatekonysaga mint az egyeni skillek.

Es nem, nem tudsz 20x hatekonyabb lenni. Ha valamit 50K sorbol lehet lekodolni, akkor nem fogod hamarabb megcsinalni, mint 5 ember. Es legfokeppen: 5 ember joval megbizhatobb. Teged elcsap a busz, elmesz a cegtol, stb..., de 5emberes csapat eseten a tudas joresze megmarad 1 ember lelepesevel. Ez a szervezetek elonye.

Marmint ugyerted hogy azokban a tipikus alkalmazasokban amire te szoktad hasznalni.

Nem, ez minden komolyabb rendszerre igaz (kellene, hogy legyen).
Az objektum azert jobb, mert validalt (csak ellenorzott, valos adatokat enged magaba), strukturalt, modositasok ellen vedett (ha szukseges). Egy stringrol sose tudod, hogy helyes-e, minden fuggvenynel kulon ellenorizni es tagolni kell. Egyszoval kerulendo.
Helperekkel kapcsolatban igazad van, de arra ugyanugy ervenyes a <<5% szabaly.

Nyilván jó dolog, ha tud valaki bytecode-ra fordítani, Perl 6 majd ezt is tudni fogja, viszont közel sem olyan fontos mint gondolnád.

Nem fontos? No nezzuk csak. Perlben vagy leprogramozol nativan valamit, akkor viszont tetu lassu lesz (lasd http://shootout.alioth.debian.org/), vagy xs-t hasznalsz, amikor mar csak jocskan lesz lassubb, viszont c kodot irtal, vagyis rogton 2 nyelvet kell tudnod es menedzselned, plusz az install-nal szopni fogsz a forditassal, stb...

Ezt most vesd ossze egy 'java -jar ez.jar' paranccsal. Meg mindig olyan lenyegtelen a bytekod forditas?

De nem ez a lenyeg. A perl baja az, hogy a platform osszes hibaja mellett maga a nyelv is egy borzalom, kozismerten a legnehezebben olvashato. Ez a ketto egyutt az en szemember azt jelenti, hogy a perl egy xar.

Viszont kapasbol PHP, Python es a Ruby megbukik rajtuk.

He? A whitespace-eken? Ne nevettess mar. Pont, hogy jo, hogy enforce-ol a nyelv egy bizonyos merteku standardot. Errol tepem epp a szam mar egy ideje.

Ahhoz hogy "use DBI;" meg nem kell megtanulni C-ben, de C sebesseggel megy.

Hamis. Egyreszt nyilvan rengeteg ido vesz egy a perl-c szerkezetek atalakitasara, masreszt meg a feldolgozas akkor is perl-ben fog tortenni. Harmadreszt, a DBI egy rossz pelda, mert az adatbazis-muveleteknel a DBMS viszi el a legtobb idot (ha nem, akkor rosszul van megtervezve az adatbazis).

Inkabb ugy erzem, hogy valamilyen okbol "you have an axe to grind against Perl".

Nem. Adtam eselyt a perlnek, meg a borzadaly szintakszisa ellenere is. De ahogy egyre jobban megismertem, egyre inkabb hanyok tole. Csak epp a legacy kodot ebben irtak az elottem itt dolgozok (ugye, milyen fontos is ez a korulmeny? csapatmunkaban nincs helye egyeni izleseknek), igy ezt kell reszelni, es kesz. Attol meg okadek, ahogy van. Shellscript-helyettesitonek jo maximum, de en spec. arra is inkabb python-t hasznalnek.

"basic, x86 ass, pascal, c, c++, java, .net, shell, python"

Nem látok sem logikai, sem funkcionális nyelveket az előzményekben. Prolog, Lisp, Haskell (hogy csak a nagyokat említsem) nem játszott előtte? Nézd meg a szintakszist, gondolkodásmódot, OO-t és utána nem is lesz olyan furcsa a Perl-é. A Perl - mint írtam - hibrid nyelv, nem lehet megítélni egy erősen procedurális-OO szemüveg mögül tárgyilagosan.

Legacy kód pedig végképp nem lehet egy vélemény alapja egy nyelvről, hiszen az jó eséllyel gányolmány általában, bármilyen nyelven legyen írva.

Végül, de nem utolsó sorban mi a véleményed arról az emberről, aki egy szülinapi ünnepségre "fa testápolóval", káromkodva érkezik és elkezdi gyalázni az ünnepeltet? Hmmm???

( doc | 2007. 12. 18., k – 15:47 )

ki gondolta volna hogy már ilyen idős...
nagyon ügyes kis nyelv, bizonyos feladatokra (pl. szöveges file-okban tárolt adatok feldolgozása) hihetetlen hatékony tud lenni
csak gyorsan kell benne programozni, mert nincs a világon annyi komment, hogy az ember pár hónap után megértse a saját perl forrását :D

"nincs a világon annyi komment, hogy az ember pár hónap után megértse a saját perl forrását": ezt hirdeti (többek közt) a Python marketing...
Tessék megtanulni tisztességesen kódolni Perl-ben, kialakítani a saját következetes kódolási konvenciót, használni a warnings és a strict pragmákat, valamint az English modult, kommentezni, ahogy minden más nyelven kell egy érthető forráshoz, stb-stb. Végül lássatok csodát: kész az olvasható, érthető, később is elemezhető, újrafelhasználható Perl kód. ;)

No igen, én x86 assemblyvel jártam így :) Megnéztem egy - amúgy magamhoz képest meglepően ügyes - két éves assemblyben írt egér-, ill alapfokú grafikai objektumkezelő rendszert... Mondanom se kell, hogy egy árva kukkot nem értettem belőle :)

Apple MacBook
CD 1.83 | 1.25GB 667MHz | 60GB SATA | 2.36 kg | 5400mAh @ 12.5V

( comet | 2007. 12. 18., k – 17:55 )

Ja egyebkent, a cikk szövege egy kicsit pontatlan vagy felrevezeto, mert valo igaz hogy 5.8.8 a stabil, es 5.9.x a fejlesztoi, de 5.10 (5 ev utan sok uj fejlesztessel) az rc2-ben van, szoval lehet akar karacsonyra kis is adjak az uj stabil verziot, sot talan meg valoszinu is.

( pwm | 2007. 12. 18., k – 21:11 )

boldog szulinapot ;) 


#!/usr/bin/perl -w                                      # camel code
use strict;

                                           $_='ev
                                       al("seek\040D
           ATA,0,                  0;");foreach(1..3)
       {<DATA>;}my               @camel1hump;my$camel;
  my$Camel  ;while(             <DATA>){$_=sprintf("%-6
9s",$_);my@dromedary           1=split(//);if(defined($
_=<DATA>)){@camel1hum        p=split(//);}while(@dromeda
 ry1){my$camel1hump=0      ;my$CAMEL=3;if(defined($_=shif
        t(@dromedary1    ))&&/\S/){$camel1hump+=1<<$CAMEL;}
       $CAMEL--;if(d   efined($_=shift(@dromedary1))&&/\S/){
      $camel1hump+=1  <<$CAMEL;}$CAMEL--;if(defined($_=shift(
     @camel1hump))&&/\S/){$camel1hump+=1<<$CAMEL;}$CAMEL--;if(
     defined($_=shift(@camel1hump))&&/\S/){$camel1hump+=1<<$CAME
     L;;}$camel.=(split(//,"\040..m`{/J\047\134}L^7FX"))[$camel1h
      ump];}$camel.="\n";}@camel1hump=split(/\n/,$camel);foreach(@
      camel1hump){chomp;$Camel=$_;y/LJF7\173\175`\047/\061\062\063\
      064\065\066\067\070/;y/12345678/JL7F\175\173\047`/;$_=reverse;
       print"$_\040$Camel\n";}foreach(@camel1hump){chomp;$Camel=$_;y
        /LJF7\173\175`\047/12345678/;y/12345678/JL7F\175\173\0 47`/;
         $_=reverse;print"\040$_$Camel\n";}';;s/\s*//g;;eval;   eval
           ("seek\040DATA,0,0;");undef$/;$_=<DATA>;s/\s*//g;(   );;s
             ;^.*_;;;map{eval"print\"$_\"";}/.{4}/g; __DATA__   \124
               \1   50\145\040\165\163\145\040\157\1 46\040\1  41\0
                    40\143\141  \155\145\1 54\040\1   51\155\  141
                    \147\145\0  40\151\156 \040\141    \163\16 3\
                     157\143\   151\141\16  4\151\1     57\156
                     \040\167  \151\164\1   50\040\      120\1
                     45\162\   154\040\15    1\163\      040\14
                     1\040\1   64\162\1      41\144       \145\
                     155\14    1\162\       153\04        0\157
                      \146\     040\11     7\047\         122\1
                      45\15      1\154\1  54\171          \040
                      \046\         012\101\16            3\16
                      3\15           7\143\15             1\14
                      1\16            4\145\163           \054
                     \040            \111\156\14         3\056
                    \040\         125\163\145\14         4\040\
                    167\1        51\164\1  50\0         40\160\
                  145\162                              \155\151
                \163\163                                \151\1
              57\156\056

( mizu v | 2007. 12. 18., k – 23:36 )

Hát én azért sokat köszönhetek a Perl-nek. Pl. ebben írtam a diplomamunkám:) Két hét alatt, nem voltam ember a talpamon, fogalmam sem volt pár nap múlva, hogy mit csinál a progi.

Aztán később is erőlködtem vele, még nagyobb projekteket is gyártottam. Elsősorban a CPAN miatt volt értelme. Aztán ahogy fejlődött a Python, az extension-ök és a lib-ek, majdnem mindet újraírtam benne. És láss csodát, egy év múlva is bátran javítgattam....

Nálam a Perl kód nem lehet 20 sornál több. Viszont regexp-es rövid scriptekre nincs nála jobb.

A Python nekem nagyon bejött, és ha nem masszív regexp-elős a történet, akkor nálam abszolut nyerő.