Perl er et skodsprog

Perl-kode er ulæseligt. Det er en sikkerhedsrisiko at bruge Perl. Perl er langsomt. Man kan ikke skrive struktureret kode i Perl. Perlprogrammører er dårlige programmører. Perl er et skodsprog!

De negative myter om Perl er mange. Og der er en kerne af sandhed i de fleste af dem: Perl har tiltrukket mange dårlige programmører, i særdelhed systemadministratorer og de første generationer af webudviklerer. Begge grupper af notorisk dårlige programmører.

Men Perl er et svært sprog, det er antitesen til bondage and discipline-familien af programmeringssprog. Sproget i sig selv påtvinger ikke programmøren nogen stil og lader derfor den stilløse programmør skyde sig selv i foden lige så tosset som han nu lægger op til. Tilgengæld har den gode programmør alle de friheder han har brug for til at udfolde sig.

Den gode programmør, der magter at håndtere mottoet om at der er mere end en måde at løse et problem på, bliver tilgengæld ikke hindret i at løse sin opgave. Gør det at alt er godt i Perl-land? Nej, enkle ting som at have "use warnings" og "use strict" som standard i sproget ville gøre det lettere for nye perl-udviklerer og værktøjer som perltidy og perlcritic burde have en meget mere central placering i perl communityet.

Men gør man sproget ret ved at dømme efter de dårligste repræsentanter for sproget? Det skulle da kun være hvis sproget udgav sig for at være et begyndersprog.

obXKCD: Selv Gud bruger Perl

Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Død Profil

Min egen erfaring er også at jo bedre man bliver til Perl, jo oftere benytter man nogen knapt så læselige strukturer - måske fordi det er hurtigere at skrive, eller man er vant til det, selvom det for nybegyndere ser helt bagvendt ud :)

Nok et af de simpleste eksempler:

if (!x) {
y;
}

vs.

y unless x;

Mvh,
Søren

  • 0
  • 0
Peter Mogensen

Perl i sig selv er skam meget nyttigt. Selvfølgelig kan det let blive noget spaghetti i forkerte hænder, men det er ikke problemet.
Problemet med Perl i efter min mening at skal man noget lidt mere end et sysadmin script, så render man hurtigt ind i at der er et vældigt rod i de libraries der er. Mange af dem er fyldt med fejl, halvfærdige og snakker dårligt sammen med hinanden. Det ville hjælpe gevaldigt på Perl, hvis der blev startet et project om at trævle CPAN igennem og checke hvor gode værktøjerne var til diverse standarder.
Hvorfor er der f.eks. mindst 3 XML DOM libraries, hvoraf det ene ikke kan namespaces? ...ja ja... TIMTOWTDI ... men, når så folk bygger oven på hver sit library, så de resulterende libraries bare ikke snakker sammen.
Det ville hjælpe at få standardiseret helt basale ting, som f.eks. XML-parsning, MIME og diverse basale protokoller.

  • 0
  • 0
Peter Makholm

For gode programmører der skal lære et nyt sprog er specielle idiomer altid lidt problematiske. Først skyer man dem for sådan gøre man ikke i C, så overbruger man dem for de er jo smarte, og endelig finder man den rette balance.

Postfix-betingelser er nok en af de meget tydelige perl-idiomer og en af dem det nok er svært at opnå en helt god balance med. At have muligheden for postfix-betingelser gør det muligt at spørge sig selv 'hvad er vigtigst, betingelsen eller det der eventuelt skal udføres?'.

Der er ikke noget helt enkelt svar. Damian Conway reserverer i Perl Best Practices postfix-betingelser til 'flow-of-control statements'. Det vil sige at i en løkke-struktur må man godt sige "next if condition()" eller "return $result if $finish". Selv bruger jeg dem også gerne til hvis jeg genererer uddata baseret på bestemte flag, altså 'print "..." if $verbose > 2' og 'print "..." if $debug' (hvis jeg altså ikke bruger et log-system istedet...).

Perl giver muligheden, den gode programmør vil finde ud af at bruge dem. Forudsat at han bliver udsat for kode skrevet af folk der har en konsistent holdning til hvordan den enkelte konstruktion bruges.

  • 0
  • 0
Mikkel Høgh

For min skyld kan i sige herfra og til dommedag at Perls gode muligheder for at lave totalt obfuscated kode er en feature og ikke en bug, og jeg kan nok også til nød give jer ret i at det muligvis kunne forholde sig sådan, hvis den kode man skriver kun er til brug for en selv, på det helt personlige plan og aldrig kommer ud på nettet eller skal vedligeholdes af andre.

Men sådan er virkeligheden sjældent, og så står vi andre stakler tilbage med kode der oftest er sværere at læse end C og BF...

  • 0
  • 0
Peter Makholm

Jeg er helt enig. Der er forfærdelig meget kode der ude der ikke er af god nok kvalitet. Desvære også centrale stykker kode. (Jeg har den ubehaglige vane at krydstjekke dokumentation og implementation når jeg har et problem, så jeg ser en del perlkode).

CPAN er på en gang det bedste ved perl og det værste ved perl. Som grundlæggende ide tror jeg at CPAN har været en meget stor styrke for perl, men det er med tiden blevet meget tydeligt at der nogle steder mangler et led til kvalitetssikring. En peer reviewed CPAN ville måske være vejen?

Ikke en ny ide, dog:
http://www.perlmonks.org/?node_id=424306
http://www.issociate.de/board/post/364666/Peer-reviewed_CPAN_modules_fil...

  • 0
  • 0
Peter Makholm

Folk der skriver skodkode gør det som regl uanset hvilket sprog de skriver i. At sproget ikke påtvinger en vis stil fjerner bare det slør at folk slet ikke har nogen stil.

Det er meget lettere at afvise et stykke kode som skod fordi det syntaktisk er ulæsligt end fordi det er semantisk meningsløst. Men folk der ikke kan skrive pænt Perl vil oftest også lave underlige ting i andre sprog.

Folk er dårlige til at programmere - nogle sprog forsøger bare at skjule det.

  • 0
  • 0
Peter Mogensen

CPAN har skam kvalitetsstempler. (a=alpha,b=beta,R=released,M=mature,S=standard)

Der bliver bare ikke gjort nok ud af dem.og de bliver sikkert ikke vurdere af ret mange andre end forfatteren selv.
Problemet er også at de ting, der var nødvendig som grundliggende værktøjer da Perl blev frigivet ikke er de samme længere. F.eks. burde XML understøttelsen være standardiseret. Og selvom LWP da er smart, så kunne det godt trænge til en oprydning.
Mange moduler er heller ikke tænkt helt igennem. Hvorfor opererer HTTP::DAV f.eks. med et CWD? .. Hvem siger at man er ved at skrive en fil-browser klient med det?

  • 0
  • 0
Peter Makholm

Sørens pointe er selvfølgelig ganske korrekt, men dækker ikke hele historien.

Sprog kan godt være gode og dårlige, det giver dog mest mening hvis man gøre sig klart hvad målet med sproget er. Det dækker både over hvilke opgaver sproget skal løse og hvem der bør bruge sproget. Der er helt klart folk der ikke bør bruge Perl, men der er også enkle ting der kunne gøre Perl til et bedre sprog for alle. For eksempel at slå ting som strict og warnings til som udgangspunkt.

  • 0
  • 0
Peter Makholm

Ja, og der er også CPANRatings.perl.org. Men hvis det ikke bliver brugt rigtigt eller nok betyder det ikke noget.

Det er også helt korrekt at der er områder der trænger til at blive genopfundet. Dels fordi at behov har ændret sig, men også fordi ting er opstået ved knopskydning.

Et andet helt klart område hvor en oprydning har været tiltrængt er email-området. Det er heldigvis igang med at ske:http://emailproject.perl.org/wiki/Main_Page

  • 0
  • 0
Anders Østergaard Jensen

Jeg er ked af at indrømme det, men jeg forstår ganske enkelt ikke intentionen eller de kryptiske, snørklede formuleringer i dit blogindlæg. Og nej, jeg kender godt Perl, men enkelte gange synes jeg, at Version2's bloggere burde køre indlægget igennem en stavekontrol, før man lægger det offentligt online i et så stort og respekteret medie.

  • 0
  • 0
Peter Makholm

Anders, jeg vil selvfølgelig hjertens gerne hjælpe din forståelse på vej. Men det kræver nok at du er lidt præcis med hvilke formuleringer du finder snørklede og kryptiske.

Intentioner? Tjaaa, enten vil jeg bare fornærme nogle systemadministratorer elelr også skal jeg bare rase lidt ud over aktikler der helt sort/hvidt udnævner dette eller hint sprog som skodsprog. Muligvis var det bare et trinbrædt til nogle mulige interessante diskussioner. Nogle gange er det lige så meget jeres feedback der er pointen som at komme med en færdigtykket kommentar.

Jeg tror i hvert fald jeg kommer til at vende tilbage til kvaliteten af CPAN.

  • 0
  • 0
Thomas Hansen

Nu foretrækker jeg selv Ruby, og Ruby har lånt nogen 'gode' (alt efter hvor man står) ideer fra Perl. Bl.a. postfix conditions. Og det er en feature jeg sætter pris på. Utallige gange når jeg koder PHP ærger jeg mig over:
if (!$hash)
$hash = array();
$hash['key'] = $val;

Fremfor det mere letlæselige Ruby:
hash = {} unless hash
hash[:key] = val

Det virker måske bagvendt hvis man tænker programmatisk 'if.. then.. else..', til gengæld er det nærmere naturlig sprog.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Der har været meget debat om omvendt perlsk notation, altså "action if cond", men vi bruger faktisk oftere den form i vores naturlige sprog, selv om begge dele er korrekt:

"Lad os tage til stranden, hvis vejret holder!"

"Tag bare et stykke kage til, hvis du kan spise det!"

Det omvendte lyder mere akavet:

"Hvis vejret holder, så lad os tage til stranden!"

"Hvis du kan spise det, så tag bare et stykke kage til!"

Perl er designet af Larry Wall, der er linguist, altså en, der arbejder med naturlige sprog. I naturlige sprog finder vi, at et rigt sprog kan dygtige mennesker formulere forunderlige ting. Jeg har aldrig hørt nogen, der synes, at sproget skal gøres fattigt, for at de sprogsvage skal stilles på lige fod med andre.

Men bevar's, hvis man ikke kan lide Perl, så kan man da bare holde sig til andre sprog. Der er nok at tage af. Klynk da endelig over Perl, så ved, vi hvor vi står. Jeg og andre kan godt skrive ordentlig Perl. Jeg har flere gange set grønne programmører skrive pænere perl kode en klynkerne gør. Man skal bare lære det på den rigtige måde.

Skal vi også lave talesproget om til ære for klynkere?

Thomas

  • 0
  • 0
Peter Makholm

Med hensyn til Ruby, så er det et sprog jeg længe har haft i kikkerten. I hvert fald siden vinteren 2002 hvor der var NordU-konference i Helsinki (det er der jeg kan huske at have købt Ruby in a Nutshell). Desvære har jeg aldrig fået taget mig sammen til at lave noget større i det, men jeg har et par projekter i støbeskeen der kan komme til at betyde at jeg skal se noget mere på Ruby.

  • 0
  • 0
Peter Mogensen

... de skal selvfølgelig bruges med omtanke i den konkrete situation.
Selfølgelig er det trælst at sidde lang tid og prøve at forstå et stykke kode for pludselig at opdage at det aldrig bliver udført. Men andre gange kan de øge forståelsen.

  • 0
  • 0
Brian Rasmussen

Du har ret i at der er mange, der siger grimme ting om Perl, og måske knap så mange, der råber højt om Haskel eller TCL. Er det fordi Perl er dårligere end de to eller er det fordi, at flere (med eller uden evner) er blevet udsat for Perl? Jeg er meget glad for Perl og bruger det ofte, men bestemt ikke til alle opgaver. Der er masser af eksempler på brugbar kode skrevet i Perl (ikke mindst hele universet), så uanset at man kan skrive noget snask i Perl, har det vel efterhånden bevist sit værd.

Jeg har oplevet forfærdelig kode i mange sprog efterhånden. De værste eksempler, jeg har set, har nok været i Java - så er Java et skodsprog? Skønt Perl da har sine finurligheder og idiosynkrasier, finder jeg det mere nærliggende at skyde skylden på brugerne end på sproget.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize