Rasmus Lerdorf fortryder én ting i PHP

Illustration:
PHP er blevet en langt større succes, end Rasmus Lerdorf kunne drømme sig til, da han udviklede sproget. Men én ting ville han gerne have gjort anderledes.

Besøger du en webside, er der er god sandsynlighed for, at det er PHP, der bliver brugt til at vise indholdet frem med. Hele 81 procent af verdens webservere med dynamiske sider kører scripting-sproget PHP.

Den udvikling havde dansk-canadiske Rasmus Lerdorf slet ikke set komme, da han i 1993 begyndte at udvikle PHP. Han stod bare selv og manglede et sprog, der gjorde det let at udvikle til serversiden på nettet, forklarer han i et interview med Infoworld.com.

»Jeg byggede min egen hammer, fordi jeg ikke kunne finde en hammer på det tidspunkt,« siger han til Infoworld.

Skulle han ændre noget i PHP, er det at få PHP til at skelne mellem store og små bogstaver i funktionerne. Det skulle han have gjort for længe siden, men det virkede bare så trivielt, sagde Rasmus Lerdorf på scenen til Devbeat-konferencen i San Francisco.

Nogle år fremme i PHP's udvikling kunne det være, at PHP til gengæld får indarbejdet en just-in-time-compiler, i stil med Facebooks Hiphop-projekt, hvor farten bliver banket i vejret ved at omdanne PHP til C++.

Læs også: Så er det officielt: Facebook forvandler PHP til C++ med Hiphop

Læs også: Dansk PHP-skaber til Version2: Facebooks PHP-værktøj er ingen revolution

Får Facebooks Hiphip et bredt nok sigte, kan det blive den næste motor for PHP, sagde Rasmus Lerdorf.

En anden mulig ændring blev dog helt afvist: PHP bliver aldrig et meget stærkt 'typed' sprog, for det ville kræve enorme ændringer, forklarede han.

Den slags stramninger er heller ikke ubetinget en fordel, lød vurderingen, for mens de dygtigste udviklere vil finde det naturligt, vil mange andre blive frustrerede over sådan en ændring, når de opdagede, at deres kode ikke virkede længere, sagde Rasmus Lerdorf.

Næste udgave af PHP, version 5.6, der kommer engang over sommeren 2014, byder i øvrigt også mest på mange mindre ændringer og ingen revolutioner.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (36)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thue Kristensen

Hvis du har et program, hvor du har to funktioner som adskiller sig kun mht versaler, så er det da en stor mulig fejlkilde, da du let kan komme til at bruge den forkerte funktion. Netop ved at dette ikke kan forekomme, som i PHP, undgås denne fejlkilde. Det er da en feature, ikke en fejl.

Jeg synes egentligt at PHP er udemærket at programmere i - der er mange steder det er inkonsistent, men jeg kender stederne og kan lade være med at bruge de inkonsistente features. Men jeg kan ikke forstå at der kun er en ting som Rasmus Lerdorf ville ændre (og jeg kan ikke læse af hans kommentarer i artiklen at han mener at der kun er en fejl).

Man kunne nævne ? :, som er venstreassociativ modsat alle andre sprog. Eller det faktum at array-opslag stille autokonverterer alle index-opslag som ikke er int eller string. Eller manglen på konsistent navngivning: gettype vs get_class.

Min egen personlige favorit er de såkaldte CSV-funktionerne, som følger deres helt eget inkompatible format som der ikke er andre som bruger, og som bestemt ikke følger RFC 4180.

  • 8
  • 0
Peter Makholm Blogger

Den slags stramninger er heller ikke ubetinget en fordel, lød vurderingen, for mens de dygtigste udviklere vil finde det naturligt, vil mange andre blive frustrerede over sådan en ændring, når de opdagede, at deres kode ikke virkede længere, sagde Rasmus Lerdorf.

Hvis vi lige kikker ud over et brud med bagudkompatibiliteten, så er min vurdering stik modsat.

For de dygste programmøre er det ikke noget problem at arbejde med et meget løst typet sprog, men mange andre vil have stor gavn af at typesystemet giver en gratis statisk analyse af at programmet giver mening.

  • 10
  • 1
Peter Makholm Blogger

Min egen personlige favorit er de såkaldte CSV-funktionerne, som følger deres helt eget inkompatible format som der ikke er andre som bruger, og som bestemt ikke følger RFC 4180.

Som der står på Wikipedias side om CSV-filer: "A general standard for the CSV file format does not exist". Self RFC 4180 siger tydeligt: "there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files."

  • 1
  • 0
Troels Henriksen

For de dygste programmøre er det ikke noget problem at arbejde med et meget løst typet sprog, men mange andre vil have stor gavn af at typesystemet giver en gratis statisk analyse af at programmet giver mening.

Jeg tror at Rasmus især tænker på de implicitte typekonverteringer i PHP. Dem er det vist kun begyndere der vil savne.

... desuden er kraftige typesystemer helt klart kun for de dygtigste programmører!

  • 1
  • 2
Thue Kristensen

Som der står på Wikipedias side om CSV-filer: "A general standard for the CSV file format does not exist". Self RFC 4180 siger tydeligt: "there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files."

Det er dog ikke nogen god grund til at PHP skulle opfinde sin helt egen nye version. Og som du kan i https://bugs.php.net/bug.php?id=22382 , så opstod PHP mærkelige "CSV"-format fordi en bruger var forvirret nok til at bruge addslashes til at escape "-er i CSV-felter, og tro at det gav mening.

Hvis man følger RFC 4180 så er man kompatibel med MS Office og OpenOffice. Der er ikke nogen grund andet en dumhed til at PHP har deres eget mærkelige format til dataudveksling, som ikke er kompatibelt med andet en PHP selv.

  • 5
  • 0
Simon Shine

Eftersom PHP muligvis er det sprog som har den mest udviklede kultur som gør grin med sproget, synes jeg det er et beskedent forbedringsønske. Magic quotes, en sammenligningsoperator som ikke er transitiv, variable-variable, eller et inkonsistent navngivet standardbibliotek... og så vælger han versalisering af funktioner.

PHP: http://farm8.staticflickr.com/7226/7095238893_5000f6e57d.jpg

Til artiklens forfatter: Facebooks Hiphip?

  • 7
  • 0
Peter Makholm Blogger

Hvis du har et program, hvor du har to funktioner som adskiller sig kun mht versaler, så er det da en stor mulig fejlkilde, da du let kan komme til at bruge den forkerte funktion. Netop ved at dette ikke kan forekomme, som i PHP, undgås denne fejlkilde.

Sålænge alle ens navne består af ascii-tegn er jeg enig.

Når vi bevæger os ud i Unicode skal man holde tungen lidt lige i munden. Hvis man vælger den den enkle løsning med bare at håndterer alt internt som enten store eller små bogstaver får man nogle få hjørnetilfælde hvor det giver en forskel om man bruger store eller små bogstaver.

Hvis man er så (u)heldig at få brugere i Tyrkiet, så falder der brænde ned. Så oplever man nemlig mystiske fejl fordi 'i' og 'I' ikke er det samme bogstav længere.

Case-insensitivitet er en ting der er lettere sagt end gjort.

  • 0
  • 0
Erik Cederstrand

Med den frekvens af WTF-moments jeg oplever, når jeg enten reviewer eller laver noget i sproget, så kommer jeg i tvivl om PHP overhovedet indeholder design, eller om 100 tilfældige programmører har rendt rundt med hver deres hammer og smadret løs på sproget uden overordnet styring.

Med let skelen til http://en.wikipedia.org/wiki/Not_even_wrong, så er PHP "not even bad design".

  • 5
  • 1
Robert Larsen

Og alligevel, selvom I synes det er så skidt et sprog, så formår det at levere 81% af verdens dynamiske hjemmesider.

Jeg bruger det også næsten dagligt helt uden problemer, og nej, det er ikke det eneste sprog, jeg bruger.

Er det ikke kun dårlige programmører, som piver over sproget?

  • 2
  • 8
Troels Henriksen

Er det ikke kun dårlige programmører, som piver over sproget?

Klart, og kun en ussel håndværker brokker sig over at skulle hamre et søm ind med en våd nudel.

Jeg vil mene at en god programmør vil beklage sig over et sprog (eller andre værktøjer) der skaber hindringer i at udtrykke ens tanker klart og elegant, og den kategori hører PHP så absolut til.

  • 16
  • 2
Kasper Hansen

Er det ikke kun dårlige programmører, som piver over sproget?

Nej - jeg tror den dårlige programmør er den som ikke kan se hvad der er galt med php ;-) At vi har mange dårlige programmører er ikke ens betydende med at sproget er godt - der kan være mange andre årsager til at sproget bliver en succes, bl.a. at selv man som arbejdsgiver kan slippe afsted med en meget lav løn til mange php-"programmører".

  • 4
  • 1
Christian Nobel

Og alligevel, selvom I synes det er så skidt et sprog, så formår det at levere 81% af verdens dynamiske hjemmesider.

50 billion flies ...

Er det ikke kun dårlige programmører, som piver over sproget?

Jo jo, og man kan jo for den sags skyld også programmere i Brainfuck eller Whitespace - men der er vel ingen grund til at gøre tingene mere besværlig for en selv end allerhøjst nødvendigt.

  • 4
  • 0
Robert Larsen

Klart, og kun en ussel håndværker brokker sig over at skulle hamre et søm ind med en våd nudel.

Jeg er ikke dygtig nok håndværker til at banke et søm i med en våd nudel...eller med en hammer for den sags skyld.

Men jeg kan skrive ganske gode programmer med PHP.
En våd nudel ville forhindre enhver håndværker i at udføre sit arbejde....det kan slet ikke lade sig gøre at lave noget som helst med det.
PHP kan sagtens bruges til at lave software med.

Så jeg synes absolut ikke at det var en særlig god analogi.

  • 4
  • 1
Robert Larsen

Jo jo, og man kan jo for den sags skyld også programmere i Brainfuck eller Whitespace - men der er vel ingen grund til at gøre tingene mere besværlig for en selv en allerhøjst nødvendigt.


Der er vel heller ikke nogen, som seriøst programmerer i Brainfuck eller Whitespace...eller hvad?

Det er der i PHP. Facebook even! Men det er selvfølgelig også en flok amatører.

  • 1
  • 3
Johnnie Hougaard Nielsen

En våd nudel ville forhindre enhver håndværker i at udføre sit arbejde....det kan slet ikke lade sig gøre at lave noget som helst med det.

En bedre analogi ville være en stor sten. Den kan bruges til at banke søm i, og med lidt omhu kan det lade sig gøre uden at smadre omgivelserne. En hammer er blot et bedre værktøj til opgaven.

Det kan selvfølgelig lade sig gøre, for en dygtig programmør, at lave gode programmer i PHP. Men den som ikke er vidende om sprogets sære krummelurer, eller ikke har solid erfaring, kommer nemt ud i en kombination af tidsspilde og klytkode. Der findes mange pænere strukturerede sprog, som giver mindre risiko for at det bliver en kamp med sproget.

  • 10
  • 0
Adam Tulinius

Det er der i PHP. Facebook even! Men det er selvfølgelig også en flok amatører.

Facebook bruger ikke den officielle PHP-implementation.

Sproget PHP har ét sæt problemer. Den officielle PHP-implementation har et ANDET sæt problemer. Facebook har undgået det værste sæt at problemer ved at skifte implementationen ud. At PHP rent overfladisk stadigvæk er grimt, er så for Facebook mindre kritisk.

PHP kan sagtens bruges til at lave software med.

Ja, men det er et dokumenteret dårligere værktøj, end så meget andet. Prøv at læse følgende link, der allerede har været nævnt én gang i tråden:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Faktisk -- hvis du ikke har læst ovenstående, eller er bekendt med alle de problemer, så stop med at skrive mere PHP til du rent faktisk har læst artiklen. Artiklen vil gøre dig til en bedre PHP-udvikler.

  • 2
  • 1
Pelle Söderling

Den største grund til vi (stor ecommerce virksomhed med et par mio brugere) anvender PHP er at det er stortset det eneste sprog som det er let at finde udviklere til i østeuropæiske lande hvor det meste af vores udvikling foregår og hvor en dygtig PHP udvikler koster ca. 15.000 kr/mnd.

Sprogets "kvaliteter" har intet med det at gøre.

Det samme er formentlig også tilfældet for mange andre større internationale virksomheder der i høj grad benytter billige udviklere fra lavtløns-lande og derfor er det relativt let at komme på store sites skrevet i PHP.

  • 1
  • 0
Torben Mogensen Blogger

PHP og mange andre scriptingssprog (Javascript, Ruby, ...) ser ud til at være "designet" af mennesker, der ikke havde et klap forstand på hverken programmeringssprogsimplementering eller teori: Nogle designvalg ser ud til at være lavet, fordi designerne ikke forstod noget så enkelt som blokstruktur eller i hvert ikke, hvordan man implementerer det. Valget at typesystem (eller mangel på samme) ser ofte ud til at skyldes, at sproget blev kodesignet med en klytkodet fortolker, hvor det ikke lige var nemt at lave en typechecksfase inden kørslen, og hvor man til typekonverteringer bruger information om den specifikke værdi, for den har man jo alligevel adgang til i fortolkeren. Så "13" bliver stiltiende konverteret til 13, hvis man skal bruge et tal, så "13"==13 er sand, det er 13=="013" også, men "13"=="013" er ikke. Selv syntaksdesignet tyder på, at der aldrig har været nedskrevet en grammatik for sproget -- der er blot lavet en ad-hoc parser klytkodet af en, der aldrig har hørt om kontekstfri grammatikker.

Når sådanne sprog alligevel bliver succeser, skyldes det alene, at de biblioteker, de bliver leveret sammen med, har løst et specifikt problem. Det grelle er så, at sprogene bliver brugt til meget andet af folk, der lærte sproget oprindeligt for at løse dette specifikke problem, men aldrig har lært andre sprog, for det er vel ikke nødvendigt, når man nu kender PHP/Javascript/Ruby/...?

  • 3
  • 1
Claus Futtrup

Jeg er ved at skrive en spec. til noget programkode - havde egentlig tænkt mig at foreslå PHP + MySQL (af alm. vane) ... men hvis PHP er skidt, hvad skal jeg vælge I stedet? (fornuftig udbredelse - ikke same problemer).

  • 0
  • 0
Adam Tulinius
  • 1
  • 0
Henrik Eiriksson

..og det er sådan set hvad det kan bruges til.

Seriøst, PHP er et clusterfuck af kosmiske dimensioner. Det er et farligt konstrueret legetøj. Og please, lad være med at komme med "..men Facebook" argumentet. Desværre er Zuckerberg den script-kiddie som har fået lov til at nedgradere dygtige ingeniører, som FB har ansat, til script-kiddies. Hvad nogle folk dog gør for penge.

PHP er et templating system som er blevet pimp'et i sådan en grad at selv Flyboy ville protestere (se evt.: https://www.youtube.com/watch?v=BWNQTqMkezc )

Nu kommer jeg selv fra en serverside baggrund hvor typecasting overraskelser skal undgås for enhver pris (f.eks financielle systemer) og fejlhåndtering skal tages yderst alvorligt (høj fejltolerance), så jeg vurderer programmeringssprog udfra disse parametre. PHP håndterer begge ekstremt ringe - specielt fejlhåndteringen.

Hvis vi ønsker en pålidelig "digitalisering"(*) i samfundet, så må onde mutationer som PHP simpelthen dø.

(*) hvilket jeg mener er et socialt skråplan, men det er en anden diskussion.

  • 2
  • 0
Johnnie Hougaard Nielsen

Det Facebook gør med PHP er noget ganske andet end at slippe nybegyndere løs med løs hånd.

Why Facebook hasn't ditched PHP

"The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style - the worst attributes of the language are avoided and coding style is rigidly enforced through a fairly tight culture of code review (failing to adhere to the style and "going cowboy" by writing sloppy code results in pitiless mockery by one's peers). Engineering management has never had to take a strong hand here; this arose largely due to key internal technical leaders just sort of corralling everyone else along."

... "The preferred strategy is to write new components in a de-coupled manner using a better language of choice (C++, python, Erlang, Java, etc)"...

  • 1
  • 0
Thue Kristensen

Så "13" bliver stiltiende konverteret til 13, hvis man skal bruge et tal, så "13"==13 er sand, det er 13=="013" også, men "13"=="013" er ikke.

Her har du glemt hvad ideen med PHP var. PHP var designet til små hjemmesider, som opererer opererer med værdier fra POST og GET. POST og GET er jo ikke typede (alt er strenge), så det giver god mening at have en operator i sproget ("==") som autokonverterer strenge til tal. Der er jo også operatoren "===", som er den man ellers altid skal bruge hvis man ikke vil autokonvertere.

Sammenligningstabellen for "==" er ofte kritiseret, men jeg kan personligt ikke finde nogle problemer med den - den har valgt de bedst mulige løsninger på et svært problem.

At "==" bruges internt i diverse funktioner, uden advarsel eller mulighed for at bruge "===", er selvfølgelig meget uheldigt. Hvis du vil kritisere PHP, så vil jeg mene det er her der skal kritiseres.

  • 2
  • 0
Palle Simonsen

ikke same problemer

I min erfaring er det adgangen til brugbart hel/halvfabrikata koblet med dygtige udviklingshuse / udviklere der tæller mere end værktøjet.

PHP, MySql, Javascript og efterhånden HTML5/CSS3 er de mest udbredte sprog/db til websider o.lign *inet baserede services på trods af diverse mere eller mindre betydende skavanker. Sammenlignet med alternativerne er der væsentligt flere valgmuligheder blandt hel/halvfabrikata og udviklere og derfor ville jeg alt andet lige, foretrække dette værktøjsvalg.

Indrømmet - der er konstruktioner i både PHP og Javascript der er farlige i hænderne på den dårlige og/eller trætte programmør. Men så undgå i det mindste den dårlige programmør :)

  • 2
  • 0
Pelle Söderling

Claus: Du har stadig ikke rigtig beskrevet din opgave.

Men imo er den bedste general purpose web-teknologi ASP.NET MVC og C# og stortset enhver anden database er mere seriøs end MySQL, men MySQL har dog den store fordel at den er særdeles let at gå til.

(hvorfor er det iøvrigt folk tror sprog og database-valg hænger sammen?)

  • 0
  • 1
Palle Simonsen

Altså, kan jeg få nogle forslag til alternativer?

Det kommer an på dit udgangspunkt:

  1. En kommerciel virksomhed/produkt. Jeg vil hurtig til markedet og kunne leve af og supporterer mine frembringelser.

  2. Det skal være sjovt. Jeg vil lære noget, jeg eksperimenterer stadig og gider ikke bare de givne løsninger. Jeg har simpelthen en bedre idé.

  3. Då må under ingen omstændigheder være LAMP

ad 1) Hvis du primært tænker intranet er MS stakken og også LAMP et godt valg med mindre du skal arbejde for nogle, der f.eks. har Notes. I den stak er der også ok muligheder.

Hvis du primært tænker internet så se dig godt for. Hvor er den kritiske masse henne? Hvor kan jeg få en jumpstart? Hvor sker der noget? Hvor sker der ikke noget? etc.

ad 2) Go for it og lad gerne os andre vide hvordan det går. Der er tonsvis af muligheder derude.

ad 3) Så stil dig op i køen af: Det må ikke være MS, Det må ikke være Apple Det må ikke være [tilføj selv] og hvil i fred.

oao

  • 0
  • 0
Claus Futtrup

Hej Pelle, Adam og Palle

Tak for forslagene til alternativer.

Sprog og database-valg hænger ikke sammen. Det er vel derfor jeg nævner dem begge to. Ja, jeg tænkte bare LAMP. Det tror jeg der er mange der gør, når vi taler om PHP (og alternativer). Jeg kunne sagtens leve med et andet valg, f.eks. MariaDB eller PostgreSQL i stedet for MySQL. Primært ønsker jeg at valget ikke er obskurt. Mainstream.

Tilbage til script sprog. C# kunne godt være et alternativ, ikke mindst er det i vækst og det ser ud til at være rimeligt udbredt ( http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ).

Hvad det skal bruges til? Jeg påtænker noget software til brug i en virksomhed - anvendt i flere sammenhænge, lad os kalde det infrastruktur. Gerne web-baseret tilgang, med fokus på let adgang for brugerne, inkl. eventuelle kommende behov fra mobiltelefoner og tablets. Det er ikke softwareudviklingen jeg skal leve af - og umiddelbart forestiller jeg mig at jeg ikke selv skal programmere det. Der skal gerne være horder af programmører, også i fremtiden, som kan arbejde med programmet. Mainstream.

/Claus

  • 0
  • 0
Baldur Norddahl

Som database vil jeg altid vælge PostgreSQL over MySQL. Der er ikke rigtig nogle fordele ved MySQL over PostgreSQL men der er rigtig mange fordele den anden vej. Så det er lidt en nobrainer.

Nu råber du på "mainstream" og hvis mainstream betyder at du skal kunne hive enhver koder ind fra gaden, så er gamet begrænset til de gamle teknologier. Du kender selv navnene på dem.

Her er et alternativt forslag:

Play Framework med Scala: http://www.playframework.com/

Du får et typestærkt sprog, hvor der er tænkt over detaljerne. Samtidig beholder du PHPs "editer, gem, tjek resultat i browseren" - instant feedback uden en lang compile cyklus.

Hvis du skal bruge noget mere backend agtigt, så er svaret Akka+Spray: http://spray.io/wjax/

Faktisk mener jeg at på serveren er Akka så stærk at den ikke er til at komme udenom.

Det er mainstream på den måde at det bygger ovenpå Java og JVM. Der er efterhånden temmelig mange der bruger de nævnte teknologier. Se bare under "selection of production users": http://akka.io/

  • 0
  • 0
Jakob Møbjerg Nielsen

MySQL har mange af de samme problemer som PHP, mærkelige konverteringer, accept af ugyldige datoer (der så ændres til en stribe nuller), etc. :P

Derfor bruger man (naturligvis?) strict mode. Det medfører bl.a. også at for lange værdier ikke trunkeres og at en ugyldig enum ikke bliver konverteret til null.

Jeg vil dog ikke argumentere imod, at det burde være normal opførsel. :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere