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

[cyner]

Ursprungligen postat av ConnyWesth

Enligt min egen erfarenhet så spar jag minst en vecka per månad på att använda kompilator med hård typning jämför med helt otypat och interpreterande.

Det är ju intressant, eftersom en vetenskaplig artikel kom fram till att det gick dubbelt så snabbt att utveckla ett program i Python jämfört med Java. Och inga tydliga skillnader i kvalitet kunde uppmätas.

Läs och begrunda:

http://www.cis.udel.edu/~silber/470STUFF/article.pdf

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

[dotvoid]

Ursprungligen postat av cyner

Det är ju intressant, eftersom en vetenskaplig artikel kom fram till att det gick dubbelt så snabbt att utveckla ett program i Python jämfört med Java. Och inga tydliga skillnader i kvalitet kunde uppmätas.

Läs och begrunda:

http://www.cis.udel.edu/~silber/470STUFF/article.pdf

Python är ett högintressant språk som används mycket till prestandakrävande uppgifter. T ex för att implementera regler i artificiell intelligens som hos spelet Civ IV eller för att hantera grafik som hos Hollywoodföretaget Pixar.

[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"...

[fr33r1d3]

Ursprungligen postat av dotvoid

Python är ett högintressant språk som används mycket till prestandakrävande uppgifter. T ex för att implementera regler i artificiell intelligens som hos spelet Civ IV eller för att hantera grafik som hos Hollywoodföretaget Pixar.

Google använder sig av en enorm mängd Python med.

[Conny Westh]

Ursprungligen postat av cyner

Det är ju intressant, eftersom en vetenskaplig artikel kom fram till att det gick dubbelt så snabbt att utveckla ett program i Python jämfört med Java. Och inga tydliga skillnader i kvalitet kunde uppmätas.

Läs och begrunda:

http://www.cis.udel.edu/~silber/470STUFF/article.pdf

Jag har aldrig testat just Python och kan därför inte uttala några egna erfarenheter av det, det jag skriver är utifrån de erfarenheter jag skaffat på egen hand.

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