F***ing l*rt: Udviklere bander mest over C++

Kommer nok ikke bag på nogen at C++ er i toppen og PHP er i bunden når der er en del forskel på sværhedsgraderne i sprogene...

Sværhedsgraderne? Tænker du over det at PHP kommer med mange fede biblioteker og API'er pr. default?

Tja. Tænker på at du ikke behøver at tænke over memory, at du ikke fejlagtigt kommer til at lave bitoperationer, istedet for normale boolean-operationer. Og så at php jo generelt bare er et mere specifikt sprog. Kan du følge mig?

Men at Javascript er i toppen kommer bag på mig...

Nej. Programmere jeg .NET eller PHP, så skal jeg stadig tænke over hukommelse.

Nej. Programmere jeg .NET eller PHP, så skal jeg stadig tænke over hukommelse.

Ah, skal vi nu ikke lige.

Det er sandt at det at kode i PHP ikke fraskriver dig fra ansvaret for at sikre dig, at din applikation ikke sluger enorme mængder hukommelse. Men PHP er et managed sprog, og det er PHP fortolkeren der sidder med det tunge arbejde -- allokere memory, sørge for at der ikke er noget der forsøger at tilgå en pointer de ikke har adgang til, alt sådan noget gøgl. Som PHP-udvikler er det eneste på den front du skal tage dig af, at følge med i hvor mange bytes du bruger, og om du kan klare dig med færre variabler og loops hvis du bruger for mange. Det er en helt anden boldgade.

Inden for web-programmering er database-forespørgsler og sidens plads det eneste der tager tid. Martin, hvis du bruger meget tid med at tænke over hukommelse, er du på et helt forkert spor.

Php har ingen mallock funktionalitet.

Ah, skal vi nu ikke lige.

Aaaaaah.... NEJ

Det kan gøre lige meget om jeg programmere PHP eller C. jeg tænker altid over pladsforbrug og forspørgselstid. Om det er at skrive/hente til/fra RAM/disk eller database.

Det er rigtigt at fortolkeren gør en del af det tunge arbejde i de managed sprog, og at man i C++ selv skal styre ejerskab og deallokering, dog findes der værktøjer til at klare dette for dig (ihvertfald det meste af vejen).
I min tid med C++ tog jeg mig altid god tid til at skrive koden og det har altid hjulpet mig. jeg har så heller ikke arbejdet med en andens kodebase eller lavet et projekt der er eksploderet i kodelinjer. Jeg kunne forstille mig at den hårrivende mht C++ (og for den sags skyld C), er at man får overrakt en kodebase, som er 1000 år gammel og kæmpe stor, og man derefter skal kode videre på den. Dette kan nemt medføre til seg faults og memory rod.
Disse ting kan man se lidt igennem fingre med i de managed sprog (og dog. I mange managed sprog er det muligt at disable garbage collectoren), da man netop har GC og ikke skal tænke så meget på det igen. Dog vil jeg pointere at en GC og så godt kan fucke op.

Jeg tænker altid over memory, pladsforbbrug og udførselstid. Lige meget hvad for sprog jeg sidder i.

Inden for web-programmering er database-forespørgsler og sidens plads det eneste der tager tid. Martin, hvis du bruger meget tid med at tænke over hukommelse, er du på et helt forkert spor.

Php har ingen mallock funktionalitet.

Næsten men ikke helt korrekt.

Det meste af tiden er hukommelse et non-issue, men du kan godt rende ind i problemer. Fx hvis du istedet for at køre et loop der kører en metode fra en klasse, kører metoden i slutningen af sig selv, og looper ad den vej. Det betyder nemlig at PHP-parseren ikke tør frigive al den data du har gemt midlertidigt i den første iteration af metoden -- når dette har kørt længe nok, kommer du op i vilde mængder memory der bliver allokeret men ikke frigivet.

Det ovenstående sker kun hvis du har hovedet under armen, og slet ikke overvejer at memory kan være et issue i PHP. Jeg lærte min lektie

Fx hvis du istedet for at køre et loop der kører en metode fra en klasse, kører metoden i slutningen af sig selv, og looper ad den vej. Det betyder nemlig at PHP-parseren ikke tør frigive al den data du har gemt midlertidigt i den første iteration af metoden -- når dette har kørt længe nok, kommer du op i vilde mængder memory der bliver allokeret men ikke frigivet.

Ah ja, manglen på tail-call optimization . Det kan tilføjes at det desværre er i problem i mange sprog, ikke kun PHP. Compileren/interpreteren vælger at allokere en ny stak når metoden kaldes næste gang, men den gamle stak smides ikke væk resulterende i netop en eksplosion i RAM forbruget.

I praksis har jeg dog aldrig oplevet at dette sker i noget jeg har kodet i PHP, medmindre der har været tale om en bug.

Der var i dette tilfælde tale om en IRC-bot. Den løb tør for memory og døde i bål og brænd hver anden time. Så i almindelige webside-scripts er problemet til at overse, men i isolerede tilfælde kan du godt komme op i at kunne spare noget RAM i hæftigt traffikerede applikationer, hvis du undgår denne slags problemer.