[rhdf]

Ursprungligen postat av Lyx

Det är precis det här jag menar. 7.5hp ~ 4-5 veckor ger knappast tillräckligt med underlag för att dömma ut ett språk

Håller med här
Egentligen behöver man nog ge sig in på att att bygga "samma" webbsida/applikation/system (kalla det vad ni vill) i de båda språken för att kunna göra en korrekt bedömning av vad som är bäst/lättast etc.

Sen är ju min personliga uppfattning att vi sitter o jämför äpplen o päron
.net är ett ramverk medan php är ett "scriptspråk" (som förvisso "muterat" till nånting mer)
Så även om det är delvis underförstått(?) så borde en korrekt jämmörelse vara mellan tex Zend och .net

[taz76]

Ursprungligen postat av Lyx

Det är precis det här jag menar. 7.5hp ~ 4-5 veckor ger knappast tillräckligt med underlag för att dömma ut ett språk

Jag ville bara poängtera att det finns folk som har erfarenhet (om än lite) med asp.net och som ändå inte gillar det. Är mycket väl medveten om att man inte blir expert på ett par veckor.. men som sagt - det var heller inte min poäng med det inlägget.

Men nu överger jag denna diskussionen för min del.. Äpplen vs päron var intressant en stund.

[tartareandesire]

Det är egentligen ganska tomma argument rakt av. Conny, du stirrar dig helt blind på dina "professionella applikationer". Även om du kanske inte känner till det själv så drivs ett stort antal av de största webbplatserna i Sverige och i alla andra länder med PHP. Att inte kalla dessa professionella är både en dumdristig och arrogant inställning.

Det går alldeles utmärkt att använda både Java, C#, PHP och Pascal i professionellt arbete och det vet alla som har den minsta lilla inblick i verkligheten. Att påstå någonting annat är helt fel. Jag förstår dock Connys inställning eftersom han verkar arbeta i gränstrakterna mellan webb och intranät och eftersom de flesta är inkörda i Windows så blir det ett naturligt val.

Självfallet finns det nackdelar och fördelar i alla språk men de allra flesta fungerar faktiskt alldeles utmärkt (med undantag för gammal asp och en del andra förlegade varianter då).

Hela den här diskussionen har förts 100 miljoner gånger redan och är ungefär lika meningsfull som att diskutera huruvida lax eller pannkakor är godast...

[Conny Westh]

Ursprungligen postat av tartareandesire

Det är egentligen ganska tomma argument rakt av. Conny, du stirrar dig helt blind på dina "professionella applikationer".

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!

[Robert]

"Professionell" i dess rätta bemärkelse är väl det som man får betalt för (eller betalt för att utföra). För att få reda ut vad som är på tapeten kan man titta på vad marknaden letar efter, lämpligtvis AF, CSobb etc under en viss tid (då bortser jag från de stora konsultbolagens införsäljningar, där är det uteslutande .net/java med lätt övervikt åt .net).

Eftersom alla underdogs alltid sparkar uppåt har .net evangelister aldrig brytt sig om php, det är bara java som är den enda riktiga konkurrenten. .net har plockat mycket idéer från java och har, enligt andra, dragit om och ligger nu steget före där man "leder" istället för "följer" med nya grepp och roliga tekniker.

[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?

[Conny Westh]

I avsaknad av bättrre begrepp så använder jag begreppet "Prpofessionell" resp "icke-professionell"-applikation i bemärkelsen "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet", i just detta resonemang, rätt eller fel, men det är oftast ganska grundläggande krav på applikationer i de projekt jag jobbat med. Det är liksom implicita krav (BIASS) eller underförstådda krav som är så självklara att man i de sammanhangen inte ens diskuterar dem. Därav begreppet "professionella" v.s. "icke-professionella".

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Begreppet "kvalitet" måste vara med redan från krav, alanys och design. Sedan är begreppen "Hård typning, Kompilering och Objektorientering" en del av kvalitetsprocessen vid kodningengsprocessen.

Slutligen ska den designade kvaliten verifieras genom testningen, därför är det viktigt med kontinuerliga tester under hela utvecklingsprocessen. Metodiken är dock lika viktig oavsett vilka typer av programspråk som används.

Jag var noga med att INTE driva det här som något relionskrig om programspråk utan betonar vikten att använda sakliga argument för olika kvalitativa egenskaper på valet av utvecklingsmiljö.

Många programspråk finns implementerade under olika utvecklingsmiljöer och det finns olika "klassbibliotek" som kan kopplas ihop med respektive utvecklingsmiljö.

Trenden går mer mot att de olika utvecklingsmiljöerna går mot någon form av intermediate-språk på binärnivå som ligger i botten på flera utvecklingsmiljöer som exempelvis Javas byte-kod och .NET-plattformens "managed"-kod (Intermidiate Language). På sikt kommer vi troligen se någon typ av grundstandard för dessa. Så all kod som skapas av kompilatorer automatiskt kommer att fungera ihop med alla "semi-kompilerade" moduler från alla programspråk, givetvis exklusive native-kod.

Då kommer troligen alla programspråk att tvingas uppnå viss "gemensam" grundfunktionalitet och att de därutöver är helt problemorienterade.

[dotvoid]

Ursprungligen postat av ConnyWesth

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Jag håller inte med alls. Jag håller med om att kvalitet är något som måste vara med hela vägen. Testningen är definitivt en oerhört viktig del i kvalitetsarbetet. Jag håller absolut inte med om att kvalitet kräver hård typning, kompilering eller objektorientering. Jag håller med om att det finns fördelar i många situationer.

Ursprungligen postat av ConnyWesth

Jag var noga med att INTE driva det här som något relionskrig om programspråk utan betonar vikten att använda sakliga argument för olika kvalitativa egenskaper på valet av utvecklingsmiljö.

Bra. För jag gillar ju inte sånt Jag har jobbat med (programmerat både systemen i sig och integration) av ekonomi- och logistiksystem som används av riktigt stora företag (Campbells Soup, Kelloggs, Telenor, Vodafone, etc) byggda i skittråkiga uråldiga språk/verktyg som definitivt hör en annan tidsålder till enligt mig. Lustigt nog skapar utvecklare funktionalitet i en fantastisk hastighet med mycket hög kvalitet mha dessa språk. Jag har sett stora konsultföretag försöka ersätta dessa system med moderna objektorienterade fina blanka bling-bling-system och misslyckas fatalt. Det beror på att språken och verktygen är skapade för ett syfte.

Detsamma med PHP. PHP skapades för ett visst syfte och passar alls inte överallt. Det finns ett visst bagage som är mindre smickrande men erfarna programmerare undviker allt detta vilket oerfarna inte gör. Vad gäller .NET har jag i de miljöer jag rör mig inte ännu sett ett bra exempel. Därför kan jag inte säga något om .NET oavsett det rör sig om C# eller annat språk.

Det är alltså inte språket i sig som löser problem. Det är personer, metodik och hur man använder sig av språket och verktygen kring det. Jag tror (hoppas) egentligen att vi är rätt överens där. Dessutom har jag nog aldrig sett ett seriöst (professionellt?) system som inte över tid byggs upp av många olika delar i olika språk. Få system kan förbli isolerade.

[Conny Westh]

Ursprungligen postat av dotvoid

Jag håller inte med alls. Jag håller med om att kvalitet är något som måste vara med hela vägen. Testningen är definitivt en oerhört viktig del i kvalitetsarbetet. Jag håller absolut inte med om att kvalitet kräver hård typning, kompilering eller objektorientering. Jag håller med om att det finns fördelar i många situationer.

Vad jag menar med att man inte kan "testa fram kvalitet" är att:

- Det går inte att testa fram kvalitet i en applikation som i grunden har en bristfällig design, eller bristfällig utvecklings-/produktionsmiljö.

Testning är givetvis OEHÖRT viktigt för att säkerställa den PLANERADE kvaliten. Men om man inte planerar för en viss kvalitet så kan inte testningen lösa det problemet. Testningen kan två saker:

- Dels verifiera att den planerade kvaliteten blir den leverade kvaliteten
- I begränsad omfattning upptäcka vissa oönskade sidoeffekter som man inte tänkt på

Problemet med testningen är att den kan aldrig höja systemets kvalitet över den nivå som systemet är planerat och designat för. För att uppnå en bättre kvalitet måte man helt enkelt gå tillbaks till ritbordet och göra om designen. I vissa fall måste man gå tillbaks så långt som till kraven.

I vissa fall till och med designa om verksamheten i sig eftersom man hittat brister i den grundläggande verksamheten. Då kan inget system i världen rädda den verksamheten hur väldesignat det än är.

[danjel]

Ursprungligen postat av ConnyWesth

I avsaknad av bättrre begrepp så använder jag begreppet "Prpofessionell" resp "icke-professionell"-applikation i bemärkelsen "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet", i just detta resonemang, rätt eller fel, men det är oftast ganska grundläggande krav på applikationer i de projekt jag jobbat med. Det är liksom implicita krav (BIASS) eller underförstådda krav som är så självklara att man i de sammanhangen inte ens diskuterar dem. Därav begreppet "professionella" v.s. "icke-professionella".

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Begreppet "kvalitet" måste vara med redan från krav, alanys och design. Sedan är begreppen "Hård typning, Kompilering och Objektorientering" en del av kvalitetsprocessen vid kodningengsprocessen.
...

Jag har svårt att se bra argument för detta, dvs att "Hård typning" och "Kompilering"
har något med de kvalitetsaspekter du lyfter fram..man måste se till sammanhanget vilken typ av applikation man utvecklar..

Har det något att att göra med "skalbarhet"..? Nej, varför skulle det det? Skalbarhet är oberoende av teknikvalet i sig.

"Kvalitet" ett väldigt otydligt begrepp i sig, vad menar man, att det skulle vara färre "buggar"
i hårt typade kompilerade program? De buggar som är svåra och dyra att lösa har inget att göra med kod som inte kompilerar eller "datatyp" relaterade buggar ..

Den i särklass viktigaste kvalitetsfaktorn är ofta "väldesignade" program dvs genomtänkt skiktning av en applikation i olika lager och korrekt användande av objekt orienterade principer för att hantera affärslogiken ..det löser ofta per automatik dessa punkter:
"kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet"...