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

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?

:)

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.

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

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.

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.

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

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

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.

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

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.

måste bara lägga in denna som ett kul inslag i debatten http://dotnetslackers.com/Community/...artoon01_3.png

He, He, den bildserien sammanfattade väl i stort sett hela diskussionen....

PHP är frihet på gott och ont :)

Trevliga framtidsutsikter finns iaf för de php'are som vässat sina skills ordentligt, t.ex: http://www.phpclasses.org/jobs/post/370.html

Jag kom på en kul grej häromdagen.. kan det vara så att kattmänniskor gillar PHP och dess egenskaper, hundmänniskor gillar ASP.NET och deras egenskaper.. vad säger ni? hehe

Personligen är jag kattmänniska.

Jag har gett en enkel argumentation hur "Hård typning" respektive "Kompilering" ger betydande fördelar vid utvecklingsarbete lite tidigare i denna tråd. det går bra att läsa tråden från början så klaranar nog ett och annat argument. Annars är du välkommen att komma med SAKLIGA argument varför du anser att "Hård typning" respektive "Kompilering" inte har något med kvalitet i utvecklingsarbetet att göra.

Jag har aldrig läst eller hört någon som kommit fram med ett enda sakligt argument.

Det var väl dagens dummaste kommentar; "Skalbarhet har inget med teknikvalet att göra!", MY GOD, vet du vad du pratar om över huvud taget???

Kvalitet är ett mångfacetterat begrepp, jag gjorde tt förtydligande vad jag anser hör till begreppet kvalitet, det är inte uteslutande av andra kvalitetsaspekter, men en delmängd.

Man fokuserar på olika kvalitetsaspekter i olika projekt, men jag räknade upp någr aav de mest elementära som jag stöter på i många av de projket jag arbetar med.

Just det, det är det jag resonerat kring hela tiden.....

Målet är: "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet".

Strategin för att nå målet är: Genomtänkta program med god struktur!

Conny: Du brukar ha vettiga kommentarer i andra forum. Men när det gäller sådant här så har du skygglappar stora som lakan.

Alla vill inte konvertera till Microsoft underbara land där inlåsning är standard och utvecklingsverktyg som kostar multum.
Att du bara orkar lägga ned tid på att käfta emot beundrar jag, men att du har den tiden fattar jag inte.

Håller absolut med dig med det tillägget att det är precis lika korkat att argumentera för PHP på samma sätt.

Dagens kommentar :D

Conny, jag har kikat lite på din "CV" på http://www.verimentor.se/medarbetare...006-02-12).htm och jag ser tyvärr inga spår av öppna teknologier, UNIX system eller ens ett standardiserad versionshanteringsystem. Bara en salig blandning av Visual Basic, Visual Source Safe, MS Office och FrontPage.

Jag fösöker såklart inte trycka ner någon utan håller mig enbart till fakta, själv kommer jag från Windows och .NET världen och jobbar nu exklusivt med *NIX system samt öppna standarder med säkerhetsinriktning. Jag har under mina många år som systemutvecklare hört många (inkl. mig själv länge sedan) tala varmt om .NET och om hur bra det var och inget annat var bättre - tills jag faktiskt tog steget och lärde mig *NIX, PHP, Python etc.. Det är lätt att stirra sig blind på en viss sak såsom att .NET är snabbare än PHP och inte se helheten och utifrån det påstå att det ena är bättre än det andra. Jag tycker att alla system är bra så länge de är professionellt utvecklade och möter kravspecifikationen och säkerhetskraven.

Diskussionen var rolig så länge den höll sig till saklighet. Men när saker som "Alla vill inte konvertera till Microsoft underbara land där inlåsning är standard och utvecklingsverktyg som kostar multum." kommer in i en diskussion som denna blir det fånigt.

Alla val man gör begränsar framtidens möjligheter på ett eller annat vis. Dessutom är Microsoftvärlden knappast dyr om man tittar på enterprisesystem...

Vem har pratat om Microsoft? Inte är det jag i alla fall, jag resonerar kring sakliga argument för "Hård typning" och "kompilering" v.s. "Lös typning" och "interpreterande" utvecklingsmiljöer.

Det finns många levreantörer som tillhandahåller "hård typning" och "Kompilatorer". Microsoft tillhandahåller både hård och lös typning samt kompilatorer och interpretatorer. jag har i denna diskussion intealls snackat om Microsoft annat än i förbigående såsom jag även gjort om Sun Microsystems Java-miljö.

Jag har många kompetenser som jag utelämnat, av flera skäl. Dels är min CV full av förkortningar och jag måste begränsa vad jag redovisar för potentiella kunder/arbetsgivare, det går inte att redovisa allt. Jag har exempelvis helt utelämnat mina många år som utvecklare i PC/MS-DOS-miljö.

Bygge ett rapporteringssytem för skogsavverkning åt Stora. Samt i samband med det så minns jag att vi byggde någon typ av UNIX-lösning i Santa Cruz Unix för att skcika filerna någonstans som jag inte minns.

Jag jobbade med ANSI C för att bygga ett transportlager till en MOBITEX-lösning. Syftet var att ett Sälj- och servicesystem skulle användas i Bell Soths mobilnät i Amerikanska södern. med replikering av transaktionspaket som skulle distribueras över MOBITEX. Bell South installerade MOBITEX i sitt nät så sent som i början på 90-talet.

Inte har jag heller tagit med att jag skrivit en terminalemulator för DNIX-operativsystem för många år sedan.

Likväl har jag inget intresse att skriva så mycket om att jag skrivit program i ADA i en Digital Equipment VAX.

Jag har även byggt ett styrprogram för en raketmotor i Pascal, C och en specialvariant av BASIC, i ett realtidsoperativ som jag inte minns namnet på. Jag minns inte namnet på tillverkaren av utvecklingsverktygen men det var INTE Microsoft.

Attans vad mycket man kommer på när man tänker tilbaks, jag har ju även programmerat i Mac-miljö med en ANSI C-kopilator för många år sedan.

IBM Cobol var väl över 20 år sedan jag testade och sen körde jag några rader COBOL i Mocrofokus utvecklingsmiljl i DOS.

Har även satt upp en komplett utvecklingsmiljö av GNU Compiler Collection både på min Windows Vista-burk och på burken med Ubuntu 9.3.

Kör även databasen MySQL, Paralellt med Microsofts SQL-Server och tidigare körde jag mycket med Sybase SQL-Anywhere. Men jag har även kört databsen från Oracle under ett antal år. Visst ja, höll på att glömma att jag även körde SQL-Base när jag använde Gubtas SQL-Windows/Centura som utvecklingsmiljö.

Som jag tidigare redovisat här i tåden så har jag skrivit nåhgra enklare program i PHP4 respektive PHP5 men det var för ett par webblösningar och inget jag fastnade för, tyckte språket kändes gammalmodigt och var att gå tillbaks till gammal otypat/svagt typad, okompilerad kodning (i likhet med Microsofts traditionella ASP), vilket är något jag lämnat bakom mig.

På Universitetet körde jag Debian och vi hade Subversionsom versionshanteringsverktyg både i Debian-miljön och i Microsoft Windows-miljön. Vi körde många olika verktyg och testade verktyg med både proprietära och andra licensmodeller.

I jobb så använder jag ofta blandade licensmodeller eftersom det inte går att låsa in sig med att bara använda en sorts licensmodell, vilken många mindre erfarna utvecklare tror. Jag kan absolut inte välja system utifrån kriterier vilken licensmodell som används, det är ju helt befängt.

Samma sak med protokoll, jag använder de protokoll som passar den specifika tillämpning elelr det uppdrag jag jobbar med och det kan vara både standardiserade eller skräddarsydda protokoll.

Jag vill även avliva en myt om att alla standarder är "gratis" eller att de är bättre än att använda skräddarsydda varianter. Standarder är ofta grova kompromisser som inte funkar att använda när man bygger skräddarsydda system eftersom kundernas behov ofta ligger långt före standardernas utveckling.

Standarder kommer ofta många år efter att den tekniska utvecklingen kommit fram till en defactostandard på matrknaden.

Jag måste välja inriktning för att kunna fokusera och bli tydlig mot marknaden. Jag tycker min CV är alldeles för spretig ändå, jag har ju hunnit pyssla med en himla massa olika saker under årens lopp. Kunder vill ha tydlighet och smal kompetens. Annars blir de förvirrade.

Jag har även använt fler utvecklingsverktyg och databser som xBASE (Clipper, dBase, FoxPro, Visual Objects)...

Så skygglappar vet jag inte om jag kan hålla med om att jag har, men du verkar inte riktigt kunna lyfta blicken från att allt måste vara av en speciell licensmodell, jag är öppen för det mesta om det fyller sin funktion och ger bra kvalitet i utvecklingsarbetet, och då måste man välja bort det som innebär lägre kvalitet elelr onödiga risker.

Jag tror de flesta här förstår vad du säger, de som inte gör det kan du nog helt enkelt strunta i :) Däremot så är du precis lika hemmablind som de som vägrar inse att PHP inte är Guds gåva till mänskligheten.

Vad du måste inse är att det finns MÄNGDER professionella, kunniga och välmående webbaserade företag som använder PHP som huvudsaklig utvecklingsteknik. Samma sak gäller givetvis .NET. Detta är FAKTA oavsett vad du eller någon annan råkar tycka. Känns lite som en del programmerare har samma tendenser som religiösa fanatiker :)

Sedan finns det vissa typer av system där något programmeringsspråk inte fungerar lika bra som ett annat men det har inte med saken att göra.

tartareandesire > Du skrev med finare ord än vad jag skrev. Håller med dig.

Skall man käfta mellan olika saker så får vi nog skaffa ett forum med endast för detta.

Explorer vs Firefox vs Safari vs G. Chrome
PHP vs .NET vs (Fast)CGI (C, Python mfl)
Mac vs Windows vs *nix
osv osv
Kan skriva längre...

Kan inte världens länder komma överens, så lär vi nog inte göra det här heller.

Vari består skygglapparna, är det du menar med att jag ser till alla lämpliga utvecklingsprodukter, både ideella OCH kommerciella, som gör att jag har skygglappar?

Rent sakligt har jag inte alls argumenterat för Microsofts utvecklingsverktyg, utan för verktyg i största allmänhet som har hård typning och är kompilerande kontra verktyg som är svagt typade respektive interpreterande. Anledningen är enligt min erfarenhet att dessa "hårdare" verktyg ger ett bättre stöd för utvecklare i utvecklingsarbetet i form av maskinell kontroll att kontrollera typning respektive ren syntaxkontroll, detta stöd är, "by definition", mindre i de "mjukare" verktygen. Följden blir att fler buggar slinker igenom till produktionsmiljön.

Jag skulle gärna se att du utvecklar ditt resonemang lite då jag inte riktigt hänger med i dit logiska argumentation.

Om du tycker gratis är "kostar multum" så är det upp till dig, Microsoft har 5 utvecklingsverktyg man stöder öppet som s.k. Freeware, dvs som är helt gratis att ladda ned och använda, Dessa ingår i produktserien Visual Studio Express: http://en.wikipedia.org/wiki/Visual_Studio_Express

Jag använder verktyg från flera olika tillverkare, både kommerciella och ideella. Eclipse är en Java-miljö jag använder bland annat. Eclipse finns i både ideella och kommerciella varianter. En kommerciell variant är OptimalJ men det är likafullt Eclipse som utvceklingsmiljö den bygger på.

Jag säger detsamma, hur orkar folk hålla på att argumentera mot sakliga argument. Varför är ni så låsta vid att inget får komma från kommerciella företag som Sun Micrososystems eller Microsoft, eller Borland eller Symantec? Förklara gärna.

Min anledning till att jag lägger energi på detta argumenterande är att jag blir så trött på människor som inte begriper vad de argumenterar om, och att man använder felaktiga grundfakta och ren okunnighet i sitt resonemang.

Därför använder jag sakliga argument som är faktaunderbyggda i mitt resonemang. Hittils har jag mer eller mindre enbart fått mothugg med känslomässiga argument, knappast några faktaargument över huvud taget, med några få undantag.

Conny: Lägg ner istället. Du muckar uppenbarligen. Ut på krogen eller något med dig istället.

tartareandesire har redan sagt det mesta (post #62) och jag mitt inlägg under också.


Jag föreslår att tråden låses, innan fler personer ger Conny mer anledningar att spinna loss.

ConnyWesth: Du glömmer nu helt bort då att .NET 3.5 har introducerat typen "variabel" på för att förenkla för utvecklarna att bygga flexiblare applikationer och för att lösa upp den strikta deklareringen.

Kan hålla med om att .NET lämpar sig bättre i stora applikationer som kräver skalbarhet. Medans det är helt värdelöst och jobba med ur ett webdesign perspektiv och dess förmåga att implementera vedertagna standarder är en styggelse. Och är man inte stöpt i Microsoft formen från början så skapar det långsiktiga drift problem från början.

Att sedan att .NET skulle prestera bättre än PHP/Python/Ruby är bara ren o skär lögn rakt av, vilket vem som helst kan prova genom o sätta upp en Linux server på en PII-266 o en Windows 2008 server och belasta den med en 300 anrop i minuten o se vilken av serverna som stukar först o behöver rebootas.

Att microsoft utvecklingsverktyg på något sätt skulle vara bättre än vilken text editor som helst är också bara ett tecken på språkkunskap. Jag programmerar i både .NET/PHP/Ruby/C++/mASM och har aldrig haft behov av en IDE miljö...

Att säga mjuk typning är sämre än hård typning är felaktigt med i den bemärkelse av hur van man är vid att göra ordentliga tester och stressbelasta sina applikationer på ett korrekt sätt. .NET utvecklare i min erfarenhet är oftast slarvigare på att följa upp optimering och testa sina applikationer fullt ut innan roll-out. Bland annat för att dom litar för mycket på sina verktyg.

Medans OpenSource utvecklare oftast förlitar sig för mycket på att alla _andra_ ska hitta deras fel innan roll-out.

I slutändan vill jag väl bara säga att du är ett litet troll helt enkelt, och din sakliga "framläggning" består av förlegad kunskap som inte är riktigt 100% förankrad i en modern utvecklingsmiljö. Där gamla konventioner fortf. får ligga till grund utan en skälig anledning. Jag föreslår att du plockar upp en bok då och då och inte bara säger "Jag har jobbat som systemutvecklare sedan 1988".. Det enda det säger i mångas ögon är "Han borde ha slutat jobba med datorer för 10år sedan."

var är fortfarande hårt typat och kompilatorn skriker direkt när du försöker fula med den. Tex följande kod kan du inte kompilera:
Ni som förespråkar löst typat språk, kan ni lista några fördelar med att koda så? Själv har jag programmerat både och, men tycker jag producerar mycket snabbare med hårt typat, då jag kan "banka" intellisense istället för att kontrollera att jag stavat propertyn rätt osv.

Oj, Oj, vad imponerad jag blir av din sakliga argumentationsteknik! (starkt ironiskt)...

Jag förstår fortfarande inte i vilket inlägg jag pushat på för utvecklingsverktyg från Microsoft?

Jag har fortfarande bara resonerat kring stark kontra svag typning och kompilerande kontra interpreterande programspråk/miljö.

Hur står det till med läsförståelsen?

Jag önskar ibland att PHP var lite mer typat, men oftast har det ingen betydelse eftersom strängar är det man för det mesta arbetar med.

Precis som .NET har ex. typeof() och parseInt() så har PHP is_int(), is_numeric() och intval(). Tre funktioner som gör tre olika saker och är ovärdeliga i PHPutveckling.

Vill man vara säker på att en variabel är av en viss typ och hur den hanteras, så skall man använda avsedda funktioner för ändamålet. Att ta saker för givet och/eller inte inse skillnaden på datatyper och hur dom beter sig är bara ett tecken på oerfarenhet eller okunskap om hur språket är uppbyggt. Förmodligen har man dålig kunskap om datatyper i allmänhet.

Det var livliga diskussioner på php-internals för inte så länge sedan (dom kommer i.o.f.s. med jämna mellanrum) om att införa någon form av type-hinting (by argument) men åsikterna var som vanligt många och olika och vad jag vet så slutade det i en patch som finns för den som vill ha det. Samma sak har det varit med returvärden från funktioner/metoder.. Där finns det också livliga diskussioner + patch(ar) som ordnar detta.

Vill man att en variabel skall ha en specifik typ/storlek/byteorder så finns funktionen pack().
Arbetar man på bitnivå så har man nog redan insett att variabeln måste vara av rätt typ (och löser det därefter).

är en av PHP styrkor, inte svagheter.

edit: en av flera idéer finns på http://wiki.php.net/rfc/typehint

Du måste förstå vad jag lägger i begreppet. Du kan bygga en web i vilket språk/teknik som helst, och det kan vara relativt "enkelt", eller så svårt till den grad att man måste skriva om hela webben, för att kunna hantera mer trafik eller data. Det är skalbarhet för mig.
Frågaställningar är tex (av ett flertal andra som inte nämns här)
- Hur hanterar man statiska filer, i ett CDN eller dedikerade filservar för att hantera dessa
- Hur hanterar man replikering av data i databasen, för att kunna köra flera DB servrar..
- Hur ska man hantera lastbalansering mellan olika webbservrar
- Stategier för cachning
- Hur hantera sessioner över flera webbservrar
m.m, m.m

Dessa frågor innefattar såklart teknikval eller produktval ..men..
du kan köra MySQL, Postgres eller SQl server, eller php .asp.net eller Java, det är skit i samma egentligen ur skalbarhetsperspektiv, frågan är i sig en arkitekturfråga.
Det är ju solklart.
Och såklart man kan kanske kommer fram till att .net eller php eller nåt..är bäst i den specifika situationen.
Självklart, du kan inte köra tex en MS Access databas, men jag förutsätter att frågan "teknikval" inte handlar om det..
Man kan argumentera för att LAMP lösningar är enklare att göra skalbara..men lets not go there

Jag använder PHP. Behöver inte hårt typade och kompilerade språk för jag skriver aldrig några buggar som kan slinka igenom.

... eller så har jag aldrig bemödat mig med att lära mig det eftersom jag inte känner något behov :)

Alltid lika kul att se hetsiga forumdiskussioner när man ska jämföra programmeringsspråk =)
Själv jobbar jag med c# asp.net mvc och webforms

1) Jag är nog inte ensam om att tycka att det vore önskvärt om ni fortsatte er lilla diskussion i PM (eller inte alls, eftersom ni aldrig kommer att kunna enas).

2) På mitt jobb ser det ut såhär:
Under ett par år har vi gått från en strikt Microsoft-miljö till en strikt OpenSource-miljö (inkl PHP). Vi var mycket skeptiska mot detta i början eftersom vi var så invanda, men nu är vi helt frälsta.

Varför? Det är inte så lätt att sätta fingret på, men här är några spontana tankar:
* Allt finns i php - Bokstavligt talat. Alla databaser - alla funktioner - alla lib. Det är bara att köra. Utan massa krångliga installationer av lib som ändå inte funkar.
* PHPs arrayer - <3 - Detta är en fantastisk, modulär, kraftfull och löjligt enkel skapelse som man i princip bygger allt kring i php, utan att ens tänka på det. Mig veterligen finns det ingen motsvarighet i något annat språk.
* Utvecklingstid - Jag vet inte hur mycket tid vi har sparat, men jag inbillar mig att det kan röra sig om flera heltidstjänster totalt sätt. PHP går så sjukt snabbt att utveckla i.
* It just works - våra datatekniker har gått från att vara sura och vresiga windowsupdate-hatare med överväxta reboot-knapps-fingrar, till sociala varelser som avslutar dagen med ett leende på läpparna.
* Pengar - Vi har sparat fantastiska summor på licenser. Jag gissar att det kan handla om någon årslön.

Det har hänt fler än en gång att vi på mässor & liknande tillställningar klagar på vårt system inför våra konkurrenter, gnäller något om att vår miljö är så svår att administrera och utveckla i. Och sedan åker vi hem och så fnissar vi lite, för att vi tycker att vi är så listiga som behåller vår största konkurrensfördel för oss själva.

Måste man enas för att ha en vettig diskussion? Låt dem fortsätta!

Om nu .NET sidan vågar fortsätta efter ditt inlägg :)

Det var intressant att läsa dessa sakliga argument, mer sånt.

Har följt den här tråden lite på avstånd ett tag nu, och Conny argumenterar faktiskt inte för Microsofts teknik, han argumenterar för teknik som bygger på kompilerade språk och med hård datatypning. Det finns flera sådana exempel, vad sägs om just .NET-familjen, Java eller C++? Alla är sådana exempel. Fördel? Vid kompilering hittar man felstavade variabelnamn, eller att man av misstag försöker trycka in en sträng i ett datum. Man slipper hitta felet efter 5 timmars felsökning..

Dock så känns det lite som att de som argumenterar emot Conny inte argumenterar emot hårt typade språk, utan argumenterar som om valet stod mellan .NET eller PHP. .NET råkar vara ett sådant exempel på hårt typad och kompilerad teknik. PHP är å andra sidan ett löst typat språk. Det har ingenting med licenser och sådant att göra hurvida man föredrar PHP framför .NET eller vice versa, det har nog snarare att göra med hurvida man vill ha ett kompilerat och/eller hårt typat språk.

Hela den här diskussionen (PHP vs. något annat språk) känns ungefär lika givande som de ändlösa diskussionerna "Linux vs Windows" eller "PC vs MAC" där de finns lite för många fanatiker för att de ska vara sunt..

(OT: Min åsikt om PHP:

PHP _är_ ett kasst språk. Jag har själv roat mig med att knacka i det. Det är inte vackert. Det är inte strukturerat. Det är inte genomtänkt. Det är en enda röra. Visst, det går att skriva kod i det med, men det finns många språk som är bättre, oavsett licensform, kompilerat/interpreterat, hårt typat/löst typat osv. osv. (Sedan ska väl tilläggas att PHP har börjat skärpa till sig, men det går långsamt..) Visst, man får väldigt gärna tycka att PHP är världens bästa språk, men det är inte någon självklarhet direkt, det finns många, många språk som är betydligt mer genomtänka än PHP..

)

Ja dessa diskussioner tenderar ju att återkomma med jämna mellanrum, men man får se dessa diskussioner som ett sätt att lära sig något, så de kan ändå vara givande på det viset..

Problemet i dessa diskussioner är att man inte helt klart fastställt vilket "perspektiv" man diskuterar utifrån. Är PHP kasst om man ser till oop och strukturfrågor som avsaknad av Namespaces,typning m.m ? Ja det är inte lika "moget" som andra språk och utvecklas relativt långsamt. Samtidigt är flexibiliteten stor och inlärningskurvan är låg.
De funktioner som finns i PHP fungerar i många fall som "wrappers", ta tex funktionen "mysql_query()", i vissa .NET projekt jag sett har man gjort statiska funktioner för att abstrahera bort komplexiteten i ADO.net, tex en funktion som "DB.query()". I princip är det då samma sak som en php funktion.

Är PHP kasst utifrån ett mer pragmatiskt perspektiv? Nej, definitivt inte. Som en annan talare påpekade så tenderar det att bli snabbare och billigare utveckling i många situationer. Utvecklarcommunityn för php är enorm, minst sagt, och tillgången till utvecklare hög, detta är också frågor som ska beaktas när man "väljer" språk och plattform.

Jo - diskussionen pendlar tyvärr mellan språk, ramverk och tillverkare. Så det blir en lite rörig diskussion. Sedan blir det också lite stökigt när de inblandades erfarenheter skiljer sig så starkt åt...

Så för att kommentera enbart PHP som språk. PHP har utvecklats av många starka personligheter med spretande viljor. Det har tyvärr gjort att språket släpar på en hel del bagage idag. Som exempel tyngs syntaxen av en hel del inkonsistens - både vad gäller namngivning, parameterordning och överlappande funktionalitet.

Så det är sant att PHP inte utvecklats under samma organiserade form som t ex Java, C++ eller C#. (Dock bör man nog komma ihåg att både C++ och Java i perioder haft stora inkonsistenser mellan olika versioner och tilllverkares kompilatorer etc.)

Men vad jag tror många missat är att PHP har utvecklats en hel del. Det finns bagage kvar som många seriöas PHP-programmerare önskar bort. Men det är naturligtvis inte så lätt. Så de flesta professionella programmerare följer ett antal best praxis, liksom programmerare i många andra språk gör. Exempel dyker ofta upp på mysql_query (se ovan). Vilket nog ganska få använder i "professionella" sammanhang - hoppas jag. Det stadiet är liksom passerat. Samma gäller för mycket annat som finns kvar i språket. PHP6 har varit på gång under många år. Mycket har flyttats till 5.3 men en del upprensning av sådant som varit flaggat som utdaterat kommer försvinna först med PHP 6.

Mer och mer av PHP:s grundfunktionalitet tillhandahålls via klasser och objekt. Det är ganska länge sedan PHP var ett renodlat procedurellt språk. Också nuvarande PHP version 5 är många år gammal och den ihophackade objektorientering som fanns i PHP 4 är utdaterad sedan länge. Dagens objektorienterade PHP har sina egenheter men har ändå stöd för namespaces, interfaces, abstrakta klasser och allt annat man förväntar sig av ett objektorienterat språk. Man kan sakna en del. Exempelvis flera konstruktorer i en klass beroende på typ och "finally" vid exception-hantering. Objektorienteringspuritaner hittar naturligtvis alltid saker att irritera sig på. De hackar ju dock friskt på C++ och andra språk också ;)

Det gäller också debatten kring kompilerade språk resp interpreterande språk. PHP är interpreterande. Att installera en opcode cache, som cachar resultatet av tolkningen av språket, är ett femminutersjobb på vilken server som helst. Det gör att PHP exekverar den intermediära binärkoden direkt istället för att interpretera koden vid varje request. Om jag inte har fel påminner det stark om JIT-kompilering för Java?

Så till typningen. Om man tittar på hur det fungerar bakom kulisserna så använder faktiskt PHP typer. PHP:s variabler lagras i en C-struktur som är bärare av data liksom en del metadata som typ och referenser. För mig är en variabel bärare av data. Typen är sekundär och enligt mig bara information om data. Mitt synsätt skiljer sig uppenbarligen mycket från andra här. Hanteringen av referenser i PHP 5 skiljer sig markant från PHP 4 (som är - just det - utdaterat) eftersom det krävs när objektorienteringen ska fungera bättre. Därmed är eg allt referenser, bakom kulisserna, tills dess att en kopia behöver skapas av någon anledning.
PHP:s hantering av typer gör det också, naturligtvis, svårt att ha konstruktorer baserade på typer... PHP har dock naturligtvis stöd för variabelt antal parametrar vilket gör att man ofta löser detta på ett annat sätt helt enkelt.

Enligt rekommendationen ska PHP köras i strikt läge. Det är tidigare inte standard och många känner inte till att PHP då bland annat varnar för variabler som inte är initierade.

Det finns mycket mer än så att gå igenom om man orkar. Problemet är att det för PHP finns tonvis med tutorials och artiklar som ger riktigt dåliga och ofta rent felaktiga råd baserat på mycket gamla versioner av PHP. Eftersom PHP är så bakåtkompatibelt fungerar mycket när det kanske hade varit bättre att bryta kompatibiliteten bakåt. Därmed försvinner inte all gammal information från webben och det blir för utomstående troligen svårt att bilda sig en uppfattning om språket hur det ser ut och hur det används i seriösa sammanhang idag.