[dotvoid]

Ursprungligen postat av ConnyWesth

Dagens !
Jag vet inte hur jag ska kunna vara tydligare och sakligare i min argumentation. Vad är det som är tomma argument? Du får nog förklara det, jag är nog ganska trög i skallen, men jag förstår inte vad som är tomma argument i det jag skriver!

Det är inte tomma argument. Men du diskuterar en viss typ av applikationer och hävdar att det och endast det är "professionella" applikationer. Det är felaktigt. DotNet funkar säkert bra. Jag har inte jobbat med det på ett sätt att jag kan ha en vettig åsikt om det. Men av allt att döma verkar inte heller du ha tillräckliga kunskaper kring PHP och dess ekosystem av kringliggande tekniker.

Ett kompilerat språk med hård typning piskar skiten ur PHP när det kommer till klassiska number crunching system. PHP har inte arrayer i egentligen mening vilket inte är så optimalt för den typen av applikationer och dess variabelhanteringen är över huvud taget inte anpassade till detta. Inte heller skulle jag få för mig att göra en desktop-applikation mha PHP - även om det faktiskt går utmärkt. Ekosystemet med olika verktyg och beprövade tekniker för desktoputveckling kring andra språk är helt enkelt bättre.

Men jag trodde vi pratade web här... och helt plötsligt är det en helt annan sak. Då är inlägget om Assembler ovan i tråden också duktigt fånigt. Man kan bygga webbapplikationer i de flesta språk men man väljer naturligtvis det språk med bäst förutsättningar och bäst ekosystem av verktyg (icke heller att förglömma de inblandades befintliga kunskaper i olika språk).

Ang hårt respektive löst typade språk. En kompilator fångar bara småslarv. Inte de strukturella problem som verkligen kan kosta tid och därmed stora pengar att åtgärda längre fram.

Även om PHP kommer från unix-sidan med ett lite rörigt arv från C och Perl så är huvudsakligen influenser från Javalägret dominerande sedan många år.

Det innebär bland annat att få professionella programmerare i java- och PHP-världen hävdar annat än att testdriven utveckling med automatiska tester måste vara en del av utvecklingsprocessen. (Eller om man gillar Fowler och kompanis finare omskrivning för oss testrädda människor - Behaviour Driven Development.) Detta är en bra metod för att undvika programmingsfel initalt men framförallt väsentligt minska risken för framtida fel vid omskrivningar och underhåll. Många hävdar till och med att om ett automatiska tester inte finns för en viss del av system så är den delen "trasig". För hur kan man vet att det fungerar om man inte har ett automatiskt test som visar att det funkar?

Man använder sig av verktyg som ger rapporter om hur mycket kod de automatiska testerna täcker, man har uppsatta continuous integration-servrar som automatiskt plockar in och bygger systemet och kör tester på olika plattformar. Mer och mer ignorerar man de gamla trasiga utvecklingsmetoderna och går mot mer lättrörliga metoder där man inte får samma stora problem med fel i analysfasen.

Och naturlgtvis använder man i "professionella" sammanhang - för att använda en i den här tråden populär fras - också normalt bytekod-cache för bättre prestanda.

Så de flesta kvalitetshöjande åtgärder, om man bortser från att man använder rätt språk för rätt uppgift, är saker som hör till ekosystemet kring ett programmeringsspråk snarare än språket i sig. Viktiga är också de metodologier utvecklarna har för att leda arbetet fram till den faktiska implementationen. Viktigast är dock att de som jobbar i ett projekt är seriösa och professionella och kan de verktyg de använder som skapar professionalitet och kvalitet. Ibland kan det också kräva en viss öppenhet för andras professionella åsikter. (Det där ordet igen)

Så kan vi inte sluta låta som snickare och kakelsättare som bråkar om huruvida en hammare eller kakelskärare är bästa verktyget?