[Clarence]

Ursprungligen postat av Nerix

Att MySQL ligger som en egen gem i stället för att vara inbyggd i core-delen betyder att utvecklingen kan ske parallellt med språket.

Borde då inte core vara fritt från allt? Jämförelsevis ligger dock mysql som extension till php (pecl install pdo_mysql - done).

Jag har själv varit med och skrivit patchar för mongodb. Ändringarna kördes in i stable på mindre än 1 vecka.
Skulle mongodb eller mysql i stället varit native så skulle patchen förmodligen inte mergas in förrän nästa version, vilket när det kommer till Ruby och PHP tar sin lilla tid.

Pecl install mongo

Det jag menar är att jag kan hitta allt och lite till, full dokumenterat, med tester som kräver att jag varken kopierar någon kod eller bryter mot några skumma, möjligen icke existerande licensavtal.

Skulle paketet vara utdaterat och finns på Github (vilket många utav paketen gör) så kan jag utan några konstigheter göra forka projektet, fixa felet, göra en pull-request var vid ägaren (förhoppninsgvis) mergar in min ändring. Vart efter paketet pushas upp till rubygems och finns tillgängligt för allmänheten.

En viktig del är även att jag får cred för patchen jag skrev, något som både Rubygems och Github fixar.

Lätt som en plätt.

Det finns 2 skillnader mot PHP här. Rubygems finns inte för automatiska uppdateringar osv och det finns BETYDLIGT mer bibliotek till PHP. Nej, allt som finns i Ruby finns inte i PHP. Det går dock åt båda hållen. Och detta gäller precis oavsett vilka 2 språk du går imellan.

Sedan kanske det är värt att nämna att siter som Github ökar överlevnaden för ett projekt. Jag har sedan drygt ett år tillbaka valt att publicera alla smådelar för mina projekt som egna gems. Små finesser som byggt efter alla konstens alla regler. Jag kan där efter publicera paketet och låta OSS-comunity:t vidareutvecklare projektet.

Jag tycker detta är riktigt bra. Det är ett område där ruby-utvecklare är mycket bättre. Med en bråkdel av utvecklarna så är antalet projekt för ruby på github drygt dubbelt så många som för php. I mångt och mycket tror jag det handlar om fördelen med en kultur som växt från början - snarare än kommit efteråt. När PHP blev gigantiskt fanns inte github eller mostvarande tjänster. Ruby har växt till sig starkast i samma era som motsvarande tjänster.

Jag menar; chansen att fler söker efter lösningar på samma problem som jag är ganska stor. Finns det fler användare så finns det även fler utvecklare som kan jobbare vidare på projektet.

Jag tror att det jag saknar mest är implementeringen av alla dessa API:er.
Om man te.x får för sig att skriva en site som jobbar mot eBay så kan man ge sig f*n på att någon redan har skrivit en gem.

Det är här du är fel ute. Bara för att det inte finns en centraliserad källa som har allt innebär det inte att vem som helst på en minut kan finna sådana saker. Skillnaden är att du får känna till ett par tre sajter eller göra en google-sökning

Själv använder jag OmniAuth. Stöd för auktorisering mot ett 30-tal siter. Implementeras med ett fåtal rader kod.

Jag tror detta kan tas som ett exempel på att du aldrig finner exakt samma motsvarigheter i olika språk. Att hitta slimmade bibliotek för respektive inloggning är lätt för PHP. Men ett samlat bibliotek för alla vet jag inte om det finns.

Hur hittar ni (PHP-utvecklare) kunder som kan tänkas betala för det här?
Utvecklingstiden måste ju vara flera gånger vad det skulle tagit att implementera samma funktionalitet i Python, Ruby eller exempelvis Haskell.

Nej. PHP-utveckling är generellt sätt både billigare och lättare att finna utvecklare för än python, ruby och haskell. Utvecklingstiden har du fått om bakfoten då du verkar tro att precis allting skrivs från scratch. Det används ofta/för det mesta ramverk, bibliotek, specialiserade plugins osv samtidigt som du har väldigt väldigt mycket inbyggt i språket så att du får mer standardiserad utveckling.

Jag tivlar på att Zend Framework har inbyggt stöd för brittiska polisens API.

Om nu obskyr kod som ingen använder skulle vara av värde kan jag försäkra dig om att det finns gott om det för PHP också.

json, mysql, sqlite3, xml-simple

Samtliga är med i en standard PHP-installation. Skulle du inte ha kompilerat med t ex mysql får du in den senaste genom en pecl install mysql

Sedan så förstår jag inte riktigt hur jag ska få api-get att fungera under något annat än Linux.
Hur gör jag i OS X, eller Windows om jag väljer att sätta mig där?

Nej under de plattformarna får du nog nöja dig med en checkout från subversion/git efter en google-sökning.

Det är därför man låser paket-beroenden. Man specificerar helt enkelt vilka version av ett paket som får installeras.

Låser man paketversionerna så blir man väl av med största nyttan av detta sätt att föra in funktioner? För mig är iallafall den enskilda ordentliga nyttan att du faktiskt kan uppdatera mjukvaran i ett steg. Men då har du såklart nackdelen med alla community-kod att du ofta inte har en aning om hur stabil den är. Prestanda-problem kan exempelvis smyga sig in utan att upptäckas i tester - och i sin tur slå ner hela systemet.

Jag är inte ute efter att övertyga dig om att PHP är bättre. Däremot så tycker jag att hela din insats i att ge dig på PHP verkar baseras på att allt ska fungera precis likadant som det språk du förälskat dig i. Om man inte kan överge det till en början tror jag inte det är någon större poäng med att försöka utöka sin värld med fler språk.

[Nerix]

Ursprungligen postat av Jine

Visa förslag på vad du vill ha i PHP som du saknar.
Det finns massor med PHP-classer, säkert mer än 22k dessutom.

phpclasses.org rekommenderas av vissa, men hatas av andra, varierande innehåll dvs.
Github har väl ett par miljoner projekt med PHP-kod med, frågan är dock vad du letar efter.

Ruby är näst största språket på Github med sina 17%.
Q.E.D

Sedan handlar inte diskussionen om vad som finns. Läs om tråden igen.
Jag är nämligen helt säker på att alla obskyra exempel på paket som jag tagit upp finns tillgängliga i PHP.

Ursprungligen postat av Jine

Angående paket och paketberoende så undrar jag vilken faktisk funktionalitet du saknar, att du inte hittar matchande paket med identiskt namn kan jag förstå - men vad är det du EGENTLIGEN vill ha. Skriv gärna lista.

Postade ett en kortare lista lite tidigare, ta en titt på den.

Ursprungligen postat av Jine

Ang. apt-get så var jag snäll och googlade åt dig; http://www.finkproject.org/

Fink är tyvärr utdaterat. Under OS X så använder jag Brew eller Port.

Dessa pakethanterare är fortfarande inte plattformsoberoende och låter mig inte specificera vilka paketberoenden mitt projekt består av.

Ursprungligen postat av Jine

Här är något läsvärt, för alla egentligen - men speciellt dig Nerix:
http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html

Det finns heller inget i Java jag inte skulle kunna göra i ASM, frågan är dock hur bra projektet skulle bli.

Kolla bara på Roller Coaster Tycoon.
Större delen av de tre första spelen är skriven i just ASM.

Sedan så kan man fråga sig vad Rails har med saken att göra.

Ursprungligen postat av Clarence

Borde då inte core vara fritt från allt? Jämförelsevis ligger dock mysql som extension till php (pecl install pdo_mysql - done).

Givetvis så får man dra en gräns någonstans.

Bryggor mellan ett språk och ett projekt, där projektet kan tänkas utvecklas snabbare än språket bör rent generellt utvecklas vid sidan av.

Chansen att någon gör någon funky i String-klassen i valfritt språk är med stor sannolikhet mindre än att något funky (användbart) implementeras i MongoDB.

Ursprungligen postat av Clarence

Pecl install mongo

Vad du ville visa med det där förstår jag inte riktigt.
Hur sätter du mongo som ett paketberoende i din applikation då?

Ursprungligen postat av Clarence

Rubygems finns inte för automatiska uppdateringar osv och det finns BETYDLIGT mer bibliotek till PHP.

Syn bara att majoriteten inte går att köra i produktion.
Möjligen att Lasse hos Lasses Fisk inte bryr sig om copy ´n paste-kod från någon random-forum, men jobbar man med lite större projekt där kvaliteten på koden är otroligt viktig så finns det (tyvärr) ingen möjlighet att använda kodbasen.

Sedan så får du gärna utveckla det där med automatiska uppdateringar.

Ursprungligen postat av Clarence

Det är här du är fel ute. Bara för att det inte finns en centraliserad källa som har allt innebär det inte att vem som helst på en minut kan finna sådana saker. Skillnaden är att du får känna till ett par tre sajter eller göra en google-sökning

För att använda koden så måste du sedan ... *trummvirvel* ...

Att kopiera kod tillsammans med alla paketberoenden tar tid, vilket kanske inte är ett problem om projektet är litet, men ställer till aningen med problem i lite större kodbaser.

Ta te.x koden jag postade i tidigare inlägget.
Projektet är relativt litet, ändå hade jag angivit drygt 30 gems.
Varje gems beroende resulterade i slutändan i 190 paket.

Ursprungligen postat av Clarence

Nej. PHP-utveckling är generellt sätt både billigare och lättare att finna utvecklare för än python, ruby och haskell.

PHP-utvecklare är rent generellt billigare eftersom komplexiteten i applikationerna som ska implementeras ofta inte överstiger svårhetsgraden för vad en 15-åring skulle klara av.

Ta bara en titt i feedback-forumet. Det är ju inte direkt rocket-science.

Ursprungligen postat av Clarence

Utvecklingstiden har du fått om bakfoten då du verkar tro att precis allting skrivs från scratch. Det används ofta/för det mesta ramverk, bibliotek, specialiserade plugins osv samtidigt som du har väldigt väldigt mycket inbyggt i språket så att du får mer standardiserad utveckling.

Det var allt bra längesedan jag träffade en PHP-utvecklare som satt i ett ramverk. Jag har heller inte sett någon fråga varken på det här forumet eller på flashback som indikerar på att folk faktiskt väljer att använda ett ramverk. Men vet vem, folk kanske utvecklar i smyg.

I min värld så ökar även implementeringstiden i samband med att mer kod behöver skrivas.

Ursprungligen postat av Clarence

Om nu obskyr kod som ingen använder skulle vara av värde kan jag försäkra dig om att det finns gott om det för PHP också.

De tror jag säkert, frågan är bara om folk verkligen orkar lägga ner tid på att leta upp den.

Som tidigare nämnt så handlar det inte om något är möjligt eller ej utan hur snabbt och enkelt det faktiskt är att utföra något.

Ursprungligen postat av Clarence

Samtliga är med i en standard PHP-installation. Skulle du inte ha kompilerat med t ex mysql får du in den senaste genom en pecl install mysql

Precis som tidigare nämnt så är det bara 4 av ~ 200 paket som fanns inbyggd PHP.

Här är listan: http://pastebin.com/Hfk9QCAn

Ursprungligen postat av Clarence

Nej under de plattformarna får du nog nöja dig med en checkout från subversion/git efter en google-sökning.

Eller så väljer jag ett språk som har en lösning.

Ursprungligen postat av Clarence

Låser man paketversionerna så blir man väl av med största nyttan av detta sätt att föra in funktioner?

Det där får du gärna utveckla, förstår inte riktigt vad du menar.

Ursprungligen postat av Clarence

För mig är iallafall den enskilda ordentliga nyttan att du faktiskt kan uppdatera mjukvaran i ett steg. Men då har du såklart nackdelen med alla community-kod att du ofta inte har en aning om hur stabil den är. Prestanda-problem kan exempelvis smyga sig in utan att upptäckas i tester - och i sin tur slå ner hela systemet.

Jag kanske skulle tillägga att mitt wild-and-crazy-alltid-nyaste-paketet-tänk bara körs på mina egna småprojekt. Skulle servern överbelastas under 30 min för mindre än 20k användare så är det inte hela världen.

Jag skulle dock inte få för mig att göra samma sak i ett större projekt, där jag har folk över mig.

Ni får ursäka min möjligen aggressiva ton, jag känner att jag hade aningen svårt att linda in mina svar i silkeshandskar

[jgabor]

Ursprungligen postat av Clarence

Om nu obskyr kod som ingen använder skulle vara av värde kan jag försäkra dig om att det finns gott om det för PHP också.

Hahahah!

Ställer mig också frågande till vad du egentligen ville ha ut av tråden, Nerix... Du vet ju uppenbarligen redan att Ruby är fullständigt överlägset på alla sätt och vis.