Kan det overhovedet diskuteres?
Et interessant foredrag på årets YAPC::Europe konference var Jon Allens foredrag The Camel and The Snake. På baggrund af en Perl- og en Python-løsning til samme opgave viser han hvordan nogle af metoderne fra Python-løsningen kan overføres til Perl.
Et 30 minutters foredrag stillede mig ikke tilfreds, så ud på nettet for at se om der ikke var andre der havde forsøgt at gøre noget tilsvarende. Men helt forventeligt er jeg blevet skuffet. Langt det meste jeg fandt havde samme niveau som dette eksempel fra blog.slickedit.com.
Nu skal jeg selvfølgelig mene at det er dårlig Perl og at han burde have indledt med at skrive 'use strict;', hvilket ville have fjernet halvdelen af hans problemer. Men bonus er dog at han eksplicit viser at han bruger en reference til at array, og så undrer sig over at han ændrer værdien af af kalderens array?
Selvfølgelig kan Perl forbedres. At 'use strict' ikke er standard er efter min mening en lavthængende frugt. Andre kritik-punkter vil det have meget mere subtile konsekvenser at ændre, for eksempel kunne man let komme til at ødelægge muligheden for at opbygge argumenterne til et fuktionskald i et array på forhånd, hvis man gave sig til at løse "problemerne" med Perls håndtering af funktionsargumenter.
Men hovedsagen er at hvis vi bare betragter alle de dårlige sammenligninger der findes ude på nettet, så overskygger dårlig og ikke-idiomatisk Perl-kode fuldstændigt de forbedringer der kan og burde laves i Perl.
Og ud over at basere diskussionen på et elendigt sammenligningsgrundlag, så overser den også ofte nogle basale designbeslutninger i sprogene: Skal sproget primært beskytte begynder eller skal det primært understøtte eksperterne' Skal sproget gøre det let eller svært at anvende ikke-standard formuleringer' Skal sproget ofre fleksibilitet for at tvinge folk til "god" kodestil?
Vi burde kunen diskuterer det på et fornuftigt plan, men empirisk set synes jeg ikke det sker?
Om Peter MakholmKommentarer (6)
Og ud over at basere diskussionen på et elendigt sammenligningsgrundlag, så overser den også ofte nogle basale designbeslutninger i sprogene: Skal sproget primært beskytte begynder eller skal det primært understøtte eksperterne? Skal sproget gøre det let eller svært at anvende ikke-standard formuleringer? Skal sproget ofre fleksibilitet for at tvinge folk til "god" kodestil?
Der bør være sprog i begge kategorier. Der, hvor problemerne kommer, er, når sprog til begyndere ikke beskytter dem (hvor det ellers ville være nemt at gøre) og hvor sprog til eksperter helt ignorerer beskyttelse mod dumme fejl.
Det er lidt ligesom jagerfly: Piloten har ikke 100% kontrol over flyet, idet computerne filtrerer kommandoerne, så man ikke overbelaster flyet. Men piloten kan midlertidigt slå nogle af disse filtre fra, så han kan lave manøvrer, der går udover de normale sikkerhedsgrænser. En ekspertprogrammør bør havde det på samme måde: Beskyttelserne er normalt slået til, men hvis programmøren skal lave noget ud over det almindelige, kan den midlertidigt slækkes.
Hvad angår god kodestil, så er det ofte et subjektivt begreb. Hvis et sprog skal indskrænke programmørens udfoldelser, så skal det ikke være fra stilistiske krav, men for at sikre bestemte egenskaber ved programmerne, f.eks. at man aldrig følger nulpointere, at man er trådsikker, osv.
Og en anden relevant xkcd: http://xkcd.com/224/ :-)
-
0 -
0
Det er jo så nemt at falde i. Bloggens forfatter er farvet af sin overbevisning og har intet ønske om at lave en fair sammenligning. Det går langt bedre i Pythons Perl/Python phrasebook (http://wiki.python.org/moin/PerlPhrasebook).
Men iøvrigt så er mangfoldighed godt. Jeg er ikke engang overbevist om at man bør benytte een og samme formel når man designer et programmeringssprog. Eksempelvis vil jeg gerne have strict når jeg skriver "programmer", men strict ville irritere mig når jeg indlejrer lidt perl i en make-fil eller andet. Det ene eller den anden default kan være lige god - programmørens evner bliver ikke sønderligt påvirket af den slags banaliteter.
Men man kan jo somme tider pive lidt over perls sigils, svage datastrukturer, manglende parameterstyring, manglende check af funktionskalds på compile-time. Sådan er der så meget. Det ændrer dog ikke ved at man kan være meget produktiv med Perl/Python/C, når opgaven er til det.
-
0
-
0
Jeg vil nødigt give udtryk for at der er rigtige eller forkerte svar på mine designspørgsmål. Efter min mening burde der end ikke være tvivl om at man ikke bør benytte én og samme formel når man designer et programmeringssprog.
Der er mange gode grunde til at programmeringssprog er forskellige. Der er ikke en størelse der passer alle. Hovedsagen er at man ikke kan samenligne Perl og Python uden at overveje hvilke grunde der er til forskellene i sprioget.
Jeg ved godt at bloggeren sandsynligvis ikke har som mål at lave en objektiv ufarvet sammenligning. Det er også helt fint at skrive en artikel med det klare mål at Python er bedre end Perl, men jeg tror at man gør Python en bjørnetjeneste når ens Perl-niveau er så horribelt. Det må kunne gøres bedre og også gerne med en holdning og ikke bare en en til en-oversættelse af koncepter.
http://xkcd.com/438/ - tak.
(Jeg har ikke læst Pythons Perl/Python phrasebook, men jeg skubber det lige på todo-listen og vender tilbage)
-
0
-
0
Jeg er forbavset over at en forhærdet UNIX-nørd som broder Makholm i det hele taget kan stille spørgsmålet.
UNIX er inkarnationen af "software tools" konceptet, mange forskellige værktøjer der er gode til hver deres ting, istedet for en 16 kg tung schweizerkniv.
Derfor giver det ikke mening at tale om hvad et "übersprog" skal kunne for hvem eller hvordan, ligesom det er en helt forkert indstilling at diskutere "om man skal lære de studerende Java eller C++".
Vi skal have sprog der passer til opgaven:
Assembler når der ikke er plads til andet.
C Til hardwarenær og performance-orienteret systemprogrammering.
C++ hvis det skal være et stort tungt "corporate" system med dyre databaser og metervis af ringbind.
Java hvis man skal lade som om det kan bruges til noget i praksis.
Javascript eller Flash hvis det skal blinke irriterende.
"Fåresyge" til EPJ systemer
Shellscripts til at boote userland
Python og Perl til at holde krigen på vestfronten i gang.
BASIC og COMAL er såmænd ikke så tossede til at lære folk at programmere til at begynde med.
og INTERCAL for at vise at der trods alt er folk der har den rigtige indstilning til hvor hellige programmeringssprog skal være.
Poul-Henning
-
0
-
0
Muligvis formulerer jeg selve blogindlæget dårligt, men følgende burde da være klart nok?
Efter min mening burde der end ikke være tvivl om at man *ikke* bør benytte én og samme formel når man designer et programmeringssprog.
Jeg mener på ingen måde at jeg taler om et übersprog.
Jeg taler heller ikke om at sammenligne assembler, Perl og Scheme. Jeg taler om at lave en nogenlunde faglig sammenligning af konkrete sprog der både i folks bevidsthed og i reel brug udfylder meget overlappende nicher i programmeringssprogslandskabet.
Jeg forsøger ikke at behandle hele universet i hvert enkelt bnlogindlæg.
-
0
-
0
Jamen, enig. Jeg ville bare være lidt hurtigere til at skippe useriøse blogs om emnet. Der er jo rigeligt med bras på internettet.
Nævnte phrasebook er værd at læse. Nok også "An empirical comparison of
C, C++, Java, Perl, Python, Rexx, and Tcl" (http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf), selvom det mere er en sammenligning af fejlhyppighed, produktivitet, eksekveringshastighed, o.lign..
-
0
-
0
Tilføj kommentar
