- “PHP berbat (PHP Sucks)” eleştirilerinin çoğu, 2012 sonrası PHP’yi görmemiş olmaktan kaynaklanıyor
- PHP 5.4’ten sonra çok şey değişti ve o tarihten sonraki dil değişimlerine bakmak gerekiyor
PHP 5.4’ten sonraki başlıca değişiklikler
- Traits (PHP 5.4)
- Kalıtım yerine composition kullanmayı mümkün kılıyor
- Tüm sınıflara dahil edilebilen trait’lere sahip olunabiliyor
- Kısa dizi sözdizimi
array() kullanmaya gerek kalmadan köşeli parantez kullanılabiliyor
- Dizi destructuring
- Dizileri geçici değişkenlere atamaya gerek kalmadan doğrudan değişkenlere atayabiliyorsunuz
- Birinci sınıf variadic fonksiyonlar
... sözdizimiyle fonksiyonlara istenen sayıda argüman aktarılabiliyor
- Generator’lar
- Bellek yoğun işleri daha verimli bellek kullanımıyla yapmayı sağlıyor
- Anonim sınıflar
- Yeni bir dosya oluşturmadan yeni bir sınıf oluşturulabiliyor
- Diğer sınıflar gibi interface de implemente edebiliyorlar
PHP 7’den sonraki başlıca değişiklikler
- Sondaki virgül
- Fonksiyon veya metot çağrılarında sondaki virgül ekleme ihtiyacı ortadan kalktı
- Arrow function’lar
- JavaScript’tekilerden biraz farklı olsa da dile iyi bir ekleme
- Null birleştirme operatörü
- Bir değeri atamadan önce null kontrolü yapmaya gerek bırakmıyor
- Null birleştirmeli atama operatörü (PHP 7.4)
- Null birleştirme operatörünün kısaltılmış bir atama sürümü de var
- Weak map (PHP 7.4)
- Dizilere kıyasla bellek açısından çok daha iyi
- Nesneler anahtar olarak kullanılabiliyor
PHP 8 sonrası değişiklikler
- Null-safe zincirleme operatörü
- Metot çağırmadan önce null kontrolü yapmaya gerek bırakmıyor
- Adlandırılmış argümanlar
- İsteğe bağlı argümanları atlamak için null kullanma zorunluluğunu kaldırıyor
- Attributes (annotasyonlar)
- Sınıflara, metotlara, argümanlara veya özelliklere annotasyon eklemek için kullanılabiliyor
- Geliştirilmiş hata işleme
- false döndürmek için exception değişkenlerine ihtiyaç kalmıyor
- Match ifadesi
- Uzun switch ifadeleri yerine daha kısa ve okunabilir bir yöntem
- Enum’lar (PHP 8.1)
- Değer ve metot içeren enum sınıfları oluşturulabiliyor
- Type hint olarak da kullanılabiliyor
- Tip güvenliği
- Tipli argümanlar, dönüş tipleri, union type’lar, intersection type’lar vb. içeriyor
- Enum’lar için de type hint kullanılabiliyor
- Constructor property promotion (PHP 8.0)
- Aşırı uzun constructor’lara artık gerek yok
- Boilerplate kodu azaltmaya yardımcı oluyor
- Readonly properties (PHP 8.1)
- Özellikleri salt okunur olarak işaretleyen anahtar sözcükler tanımlanabiliyor
Performans
- PHP 5.6’dan 7’ye geçişte %400 performans artışı
- PHP 7’den 8’e geçişte %20 performans artışı
- Çoğu web geliştirme kullanım senaryosu için yeterli performans sunuyor; daha özel gereksinimler varsa uzmanlaşmış bir dil tercih edilmesi öneriliyor
Sonuç
- PHP ölmedi ve artık en kötü dil değil. Dil 2012’den sonra ciddi biçimde değişti; bu yüzden bu konudaki görüşleri güncellemenin zamanı geldi.
- Traits, kısa dizi sözdizimi, dizi destructuring gibi pek çok özelliğin eklenmesiyle PHP daha verimli, daha okunabilir ve bakımı daha kolay bir dil haline geldi.
- Buna hata işlemedeki iyileştirmeler, attributes’in eklenmesi ve uzun süredir beklenen enum’ların gelişi de eklenince, PHP’nin web geliştirme için sağlam ve güvenilir bir seçenek haline geldiği açıkça görülüyor.
- Bu yüzden biri PHP’nin en kötü dil olduğunu söylüyorsa, rahatlıkla geçmişte kaldığını söyleyebilirsiniz.
GN⁺ görüşü
- PHP’nin dilsel evrimine bakınca artık eski PHP olmadığını görmek mümkün. Buna rağmen birçok geliştirici hâlâ geçmişteki algıda takılı kalmış görünüyor.
- Trait’ler, kısa dizi sözdizimi ve destructuring assignment gibi kodu daha kısa ve okunabilir yapan pek çok özellik eklenmiş. Bunun bakım yapılabilirliği de artırması beklenebilir.
- Generator ve weak map gibi bellek verimliliğini artıran özellikler de dikkat çekiyor. Büyük veri işleme senaryolarında faydalı olabilirler.
- Enum ve tip güvenliğindeki iyileştirmeler gibi, dilin olgunluğunu artıran değişiklikler de var. Temiz kod yazmayı kolaylaştırması beklenebilir.
- Özellikle PHP 8’deki performans iyileştirmeleri etkileyici. Gerçek benchmark sonuçlarının NodeJS ve Go’ya yakın performans gösterdiği söyleniyor.
- Ancak legacy PHP projelerini modernleştirmek kolay bir görev değil. Kod migrasyonu ciddi kaynak gerektirebilir.
- PHP, WordPress gibi birçok açık kaynak ekosisteminin temel dili olmaya devam ediyor. Sadece dil özelliklerine bakarak PHP’nin değerini küçümsemek zor görünüyor.
40 yorum
PHP'nin neden hâlâ berbat olduğunu gayet iyi gösteren yorumlar bunlar.
Kokmayan bir bok hâline gelmiş olmanızı tebrik ederim.
Fırsatınız olursa bok dışında başka şeyler de tatmayı deneyin : )
Oldukça çok yorum geliyor. Ben bir PHP geliştiricisi değilim. Toplulukta körüklenen PHP nefretini görünce, junior arkadaşlarda da böyle duygular oluşuyor ve bu kısır döngü tekrar ediyor gibi geliyor bana. Usta bir zanaatkâr asla aletlerini suçlamaz. PHP geliştiricileri, her zaman moralinizi yüksek tutun.
Bir PHP geliştiricisi olarak... başka dilleri kullanan insanların kibri gerçekten küfür ettirecek düzeyde.
Neden başkasının kullandığı dili küçümsemeden duramıyorlar, anlamak imkânsız.
Ben de PHP geliştirirken Java'ya yöneldim, Python da denedim, Node.js de denedim ama...
Her dilin kendine göre anlaşılması zor bir felsefesi ya da rahatsız eden yanları var; neden özellikle PHP'ye sövmeden duramıyorlar, anlamıyorum...
Kahretsin, neden böyle davranıyorlar-
PHP'nin hatası denilen durumlar da, gerçekten geliştirme yaparken
bunları bilmeseniz bile neredeyse hiç kullanılmayan sözdizimleri ya da yapılar oluyor
ve böyle legacy şeyler diğer dillerde de az çok var.
Gerçekten bıktım usandım
Geçiminizi sağladığınız teknoloji hakkında konuşmuş olmam nedeniyle özür dilerim. Niyetimden bağımsız olarak sonuçta koxel'nin duygularını incittiysem bunun sorumluluğu bana aittir.
Ancak ben sadece, her şeyin acele kod yazmaktan ibaret olduğunu sanan PHP geliştiricileri arasında junior olarak koştururken hissettiklerimi yazdım. Bazı PHP geliştiricileri, best practice'lerin değiştiğini bile kabul etmiyor ve buna direniyor. Beni bunaltan nokta buydu. Şu anda koşullar gereği ağırlıklı olarak frontend sektöründe çalışıyorum, ancak JavaScript geliştirme yöntemleri hakkında da eleştirilecek pek çok nokta olduğunu düşünüyorum. Herhangi bir dilin mutlak üstünlüğü olduğuna inanmıyorum; duruma göre farklı ölçütlerin uygulanması gerektiğini düşünüyorum.
Görünüşe bakılırsa mesele, acemi geliştiricilerin hatalı programlar yazmasına izin veren yapının kendisiymiş.
Ama bu diğer diller için de aynı değil mi?
Her dilde best practice diye bir şey olmasının nedeni de zaten bu..
WordPress’e göre PHP 5.6 ve altı sürümlerin kullanım oranı %5’in altında.
https://wordpress.org/about/stats/
Buna rağmen WordPress, 2023’te PHP kurulumları için asgari gereksinimi 7.0’a yükseltti.
Kişisel olarak PHP'den hoşlanmama düzeyimle Javascript'ten hoşlanmama düzeyim neredeyse aynı.
Bu ikisiyle kıyaslayınca Python ise en azından göze o kadar da kötü görünmüyor
Kariyerime PHP ile başladım ve kariyerimdeki yükselişi de sanırım PHP sayesinde yaptım.
Şimdi ekmeğimi başka dillerle kazanıyorum ama
Yan projelerde ya da hobi amaçlı olarak ara sıra yine PHP'yi açıyorum.
Bence hâlâ çekici bir arkadaş.
Elbette bu aralar birçok alternatif çıktığı için biraz üzücü ama
Laravel Vapor fena değil.
Şu anda web geliştirme yapmıyorum ama... eski anılar işte.
Görünüşe göre birçok kişi PHP'den hoşlanmıyor. Ben de PHP'yi yaklaşık 3 yıl kullandıktan sonra, bir dil olarak gerçekten cazibesinin düşük olduğunu uzun süre düşündüm; RoR ile tanışıp Ruby adlı dilin zarafetine derinden kapılmamın sebebini bana PHP'nin sunduğunu söylesem yeridir.
Ama PHP ilk çıktığında gerçekten inanılmazdı! O zamanlar CGI ile forum yazıp durduğumuz dönemdi. O dönemde PHP'nin sunduğu çeviklik tam anlamıyla sansasyon yaratmıştı. PHP'nin web geliştirmede büyük bir ufuk açtığı da bir gerçek gibi görünüyor. :)
Ama yeni şarap yeni tulumlarda saklanır...
PHP dil olarak hâlâ en kötü dillerden biri olsa da,
bir platform olarak PHP’nin (uygun ifadeyi bulmak zor) düşündüğümden daha iyi olduğunu düşünüyorum.
Özellikle MVP ile erken büyüme aşamasındaki projelerde, ileride başka bir dil/platform/framework’e (genellikle Spring) geçileceğini en baştan netleştirirseniz,
ondan sonra dilin kusurları o kadar önemli olmuyor ve gözünüze sadece PHP’nin avantajları çarpıyor.
Sadece dosyaları kesinti olmadan düzenleyerek bile deploy yapılabildiği için kullanıcı geri bildirimlerini daha hızlı yansıtabilirsiniz;
PHP(-FPM)’in diğerlerine kıyasla özellikle iyi yaptığı verimli request queue işleme, beklenmedik yüksek trafikte (kısa süreli büyümede) daha iyi dayanmanızı sağlar;
hata olsa bile tüm uygulama çökmez ve bellek sızıntılarından da bir ölçüde bağımsız olduğunuz için iş mantığı + a kısmına odaklanabilirsiniz;
ve PHP’yi daha önce hiç kullanmamış, ana dili başka olan geliştiriciler bile bir hafta baktıktan sonra çoğu işi yapabilecek kadar kolay öğrenebilir...
Bunların hepsi ölçek büyüdüğünde (hatta belki ciddi) dezavantajlara dönüşebilir ama...
En azından MVP ölçeğinde, kullanıcı geri bildirimini alıp hızla uygulamak ve hızlı büyümek zorunda olduğunuz bir durumda PHP kadar uygun başka bir seçenek var mı?
Üstelik PHP’yi seçerken zaten “iş büyürse başka bir dile taşırız” diye en baştan karar vermiş oluyorsunuz; o yüzden cidden... Why not?
Ben biraz farklı düşünüyorum; tek başına bir MVP ortaya çıkarmak için DB şeması, WAS ve UI olmak üzere bu üç şeyi en az kodlamayla hayata geçirecek araçlara ihtiyaç olduğunu düşünüyorum. Ve PHP’ye alternatif olarak Ruby on Rails ile Django’nun harika seçenekler olduğunu düşünüyorum.
Django örneğinde, Active Record deseniyle (gerçekten eski bir terim) yalnızca model sınıflarını tanımlasanız bile DB şeması ve idare eder bir back-office CRUD UI ortaya çıkıyor. Kimlik doğrulama, erişim kontrolü, form doğrulama, DB migration araçları, test araçları gibi en azından asgari bir web servisi geliştirmek için gereken araçlar sağlanıyor. Kişisel olarak, 2000’lerin sonlarında web programlamaya başladıktan sonra Django kadar yüksek üretkenlik yaşadığımı hatırlamıyorum. SPA yaklaşımı yaygınlaştıktan ve frontend ile backend rolleri ayrıldıktan sonra ise üretkenliğin aksine azaldığını bile hissediyorum. Çünkü en az iki kişinin kullanıcı akışını anlaması ve protokol üzerinde uzlaşmış şekilde çalışması gerekiyor ki işleri paralel yürütebilsinler.
PHP web uygulamaları için bir şablon dili olmayı hedeflediyse, bence dil seviyesinde web zafiyetlerine karşı savunma araçları sunmalıydı. Modern PHP tarzının framework tabanlı geliştirme yaklaşımını benimsemiş olması da bunun bir kanıtı sayılabilir.
Ve PHP'nin genel amaçlı bir betik dili olarak tanımlanmasının üzerinden de epey zaman geçti.
Dilin neden framework ile karşılaştırıldığını anlamıyorum.
Ruby on Rails ve Django konseptine sahip Laravel var.
Modern PHP artık “modern” olarak görülmeyip PHP’nin standart geliştirme yöntemi olarak yerleştiğinde ve WordPress dahil CMS’ler modern PHP’yi benimsediğinde, PHP’nin güvenli bir genel amaçlı dil olarak insanlar tarafından algılanacağını düşünüyorum. Güveni yeniden kazanmak, genellikle güveni kırmaktan daha fazla emek ister.
Bunun nedeni, geriye dönük uyumluluğu koruma bahanesiyle yeni başlayanların yalnızca PHP'nin temel işlevleriyle güvenli olmayan web servisleri oluşturmasına izin vermesi.
PHP tutorialdiye aratınca, üst sıralardaki 5 siteden resmî PHP sitesi dışında, XSS'ye karşı korunmak için süperglobal değişkenlerin (superglobal) içeriğini çıktılarken HTML escape uygulanması gerektiğini içeren bir örnek yok. Resmî olarak sundukları kılavuz web geliştirmenin içeriğini de kapsadığına göre, PHP hem dilin hem de framework'ün rolünü birden oynuyor sayılmaz mı?Süperglobal değişken adları üzerinden HTTP'nin çeşitli öğelerinin varsayılan olarak sunulması hakkında ne düşünüyorsunuz? Ben, bir dilin ifade ettiği içeriğe göre genel amaçlı kullanım kapsamının ve kullanım alanının belirlendiğini düşünüyorum.
Örnek olarak verdiğiniz
$_GET,$_POSTgibi süper global değişkenler, PHP CGI ve SAPI modunda kullanıldığında ortaya çıkan değerlerdir. PHP CLI olarak kullanıldığında bu değerler ortaya çıkmaz.Bu tür süper global değişkenler, PHP’yi çalıştıran runtime olan PHP-CGI, PHP-FPM vb. tarafından sunulan bir API türüdür; dil olarak PHP’nin spesifikasyonu değildir.
Daha önce bahsedilen “şablon dili olmayı hedefleyen PHP” de, sıkı konuşmak gerekirse PHP’nin kendisi değil, PHP’nin runtime’larından biri olan CGI’nin bu şekilde kullanılmasını istemesidir.
Aynı şekilde, güvenlik açığı olarak anılan çok sayıdaki PHP yerleşik fonksiyonu da PHP extension’larının sunduğu fonksiyonlardır; PHP adlı “dil”in sahip olduğu özellikler değildir.
Söylediğinize göre,
JavaScript, tarayıcıyla iletişim kurmak için tarayıcının sunduğu API’leri kullanan ve zaten başlangıçta bunun için tasarlanmış bir dil ve framework olurdu;
Java bir dil olsa da, fiilen JDK’nin sayısız API’sinden yararlanmak için kullanılan bir framework olurdu;
ve diğer tüm diller de, dilin kendi spesifikasyonundan bağımsız olarak, standart kütüphane veya API sağlıyorlarsa bütünüyle framework sayılmaları gerekirdi.
Elbette aralarında ayrılmaz bir ilişki olduğu doğru, ancak bu tür noktaları gerekçe göstererek PHP’nin bir framework olduğunu iddia etmek pek ikna edici değil.
Ve 2024 Mayıs itibarıyla bile WordPress core projesinde XSS’in yamalanıyor olması, yalnızca PHP sözdizimi düzeyindeki iyileştirmelerle XSS’in engellenemediğini gösteriyor gibi görünüyor.
Frontend framework’leri, sunucu tarafı şablon motorları vb., veriden render edilebilen tüm içeriklere topluca HTML escape uygular ve yalnızca escape’in açıkça devre dışı bırakıldığı durumlarda güvenli olmayan biçimde çıktı üretir. PHP’de böyle bir işlemi topluca uygulamak için üzerinde uzlaşılmış bir yöntem yok. Eğer
echoya daprintifadeleri varsayılan olarak escape desteği sunsaydı, kısa vadede çalışmayan kodlar hızla artardı; ancak uzun vadede birçok kişinin escape eklemeyi unutma hatasını azaltabilirdi.Evet, dili ve çalışma ortamını ayrı görme bakış açısına katılmıyorum; çalışma ortamının bir şekilde dili etkilediğini düşünüyorum. JavaScript örneğinde iki çalışma ortamı var:
nodejsve tarayıcı. Python'da ise birçok uygulama bulunuyor, ancak baskın olanıncpythonolduğunu düşünebilirsiniz.Asıl yazının konusu sözdizimsel iyileştirmelerle sınırlı, ama ben bu çerçeveden biraz daha geniş bir kapsamda konuşmak istemiştim.
> Ayrıca Laravel’in açık kaynak katkıcıları tarafından değil, Rasmus ya da Zend gibi şirketler tarafından, 2011’de değil 2007 civarında, ayrı bir proje olarak değil resmi dil özelliği olarak çıkması gereken bir şey olduğunu düşünüyorum. Python 3’ün kısmen geriye dönük uyumluluktan vazgeçmesi nedeniyle benimsenmesinde aksaklıklar yaşandı ama bence PHP’nin de 5 sürümü civarında büyük çaplı bir geriye dönük uyumluluk temizliği yapması gerekiyordu. PHP’nin değişimi sanki her zaman çağın akışının biraz gerisinden geliyor gibi.
Bu aynı zamanda yukarıdaki yoruma bir yanıt niteliğinde.
Söylediğiniz açıdan bakınca PHP’yi bir tür web framework’ü olarak ele alabileceğimiz fikri aklıma yatıyor.
Ama verdiğiniz örneklerdeki XSS filtresi, escape işlemleri vb. birçok özelliği PHP’nin varsayılan olarak sağlaması gerektiğini düşünmüyorum.
En yaygın PHP-FPM ile Django ve RoR aynı konumda değil. Daha çok Flask, Sinatra ve Express’e yakınlar.
PHP-FPM, routing (dizin tabanlı), istek yorumlama (
$_GET,$_POST,$_FILE,$_COOKIE), yanıt gönderme (echo,print), oturum yönetimi ($_SESSION) dışında bir işlev üstlenmiyor.Flask farklı mı?
Flask’ta HTML escape edilmiş bir yanıt döndürmek, sadece
returnile çözülen bir şey değil.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
Sinatra farklı mı?
Aynı şekilde ayrı bir escape kütüphanesi kullanmak gerekiyor.
https://sinatrarb.com/faq.html#escape_html
Express farklı mı?
Burada da durum aynı; ayrı bir escape kütüphanesi kullanmak gerekiyor.
https://expressjs.com/en/resources/middleware.html
Örnek olarak verdiğiniz kütüphanelerin hiçbiri o framework’lerin resmi olarak sunduğu kütüphaneler değil.
Öyleyse neden PHP’nin bu tür özellikleri mutlaka resmi olarak PHP içinde sunması gereksin?
“İstek verisini hangi çılgın framework süper global değişkenlerle açığa çıkarır, güvenlik açısından sorun olmasa bile bu kullanıcıya saygısızlıktır!” gibi
zaten birçok kişinin dile getirdiği gerekçelerle PHP’nin berbat olduğunu savunuyorsanız, onu anlarım;
ama söylediğiniz “PHP’nin temel özellikleri full-stack framework’lerin sunduğu kadar yeterli değil” gerekçesine... en azından ben katılmakta zorlanıyorum.
Express’i daha modern ve daha sistemli kullanmak için Nestjs diye bir şey ortaya çıktıysa, PHP’yi de daha modern ve daha sistemli kullanmak için Laravel diye bir şey ortaya çıktı diye düşünürsek...
diğer framework’lerle (dillerle) karşılaştırıldığında öne çıkan dezavantajlardan ziyade, benim ilk yorumumda söylediğim gibi PHP(-FPM)’ye özgü avantajlar daha baskın görünmez mi?
Eski anılarımı yoklayınca, en azından
slim+twigkombinasyonu yaygınlaşmış olsaydı projelerde yaptığımız PHP hatalarını azaltmanın mümkün olabileceğini düşünüyorum. Elbette o dönemde diğer PHP geliştiricileri PHP'de doğrudan kod yazmaya alışkın oldukları için bunu devreye alamamıştık. Neyse ki PDO standart kütüphanede vardı, bu sayede SQL injection'a karşı önlem alabiliyorduk.Orijinal yorumda değinilen bug etkisini sınırlama ya da işleme performansı konusunda özellikle olumlu ya da olumsuz bir görüşüm yok. Olursa iyi bir özellik olduğunu düşünüyorum, ancak throughput patlaması ya da bellek kullanımı sorunları büyüme aşamasında en az bir kez düşünülmesi gereken meseleler olduğu için, bu tür sorunların mümkün olduğunca erken ve açık bir biçimde ortaya çıkmasının iyi olduğunu düşünüyorum
> Elbette o dönemde bunu devreye almak mümkün değildi; çünkü diğer PHP geliştiricileri PHP’de doğaçlama kod yazmaya alışkındı.
> Çünkü PHP ile düzgün geliştirme yapabilen insanların değişmesi en çok zaman alan ve en zor kısım.
Bana kalırsa PHP’nin kendisinde esaslı bir sorun yok; ya yeterince başa çıkma yöntemi var ya da diğer dillerde olduğu gibi makul gerekçelerle ortaya çıkmış farklar var. Ama bahsettiğiniz insan kaynağı meselesi... gerçekten de en büyük sorun bu olabilir.
PHP’yi ciddi şekilde kullanabilecek geliştiriciler, çoktan eski PHP’den bıkıp usandıkları için yıllar önce PHP’den kaçtı gitti;
geride kalan kullanıcıların çoğu ise PHP ne kadar gelişirse gelişsin ona gerektiği gibi bakmayan ya da buna ayıracak kapasitesi olmayan insanlar...
PHP’nin uygun olduğunu düşündüğüm MVP+a projelerine ilk gruptaki deneyimli insanların katılması için bir neden yok,
katılsalar bile ya PHP’yi seçmezler ya da PHP’yi seçseler bile ikinci gruptan bir iki kişi araya girdiği anda her şeyin karmakarışık olacağı çok açık... haha
En azından ülke içinde tatmin edici düzeyde PHP geliştirme yapabilecek insan bulmak başlı başına kolay değil.
Böylece PHP yine seçenekler arasından çıkıyor, ortalama insan kaynağı seviyesi daha da düşüyor ve bu sonsuz biçimde tekrarlanarak bir kısır döngü yaratıyor gibi görünüyor.
~~Böyle böyle en azından 1 ila 3 kişilik küçük projelerde bile~~ düzgün PHP projelerini deneme örneklerinin artması gerekiyor ki bu kısır döngü kırılabilsin diye düşünüyorum.
Gerçi ben de PHP’nin sağladığı gelirin çok büyük olduğunu söyleyemem. Tatmin edici insan kaynağı bulmak o kadar zor ki PHP’yi ana stack olarak benimsemek isteseniz bile benimseyemiyorsunuz; gerçek durum bu...
Bunun nedeni, genel amaçlı diller ile PHP arasında HTML sayfaları üretme biçimi açısından bir fark olmasıdır. Flask, en azından 1.0 sürümünü yayımladığından beri insanları bir şablon motoru kullanmaya teşvik etti ve buna bağımlı olacak şekilde tasarlandı. HTML sayfaları ile sunucu tarafı verisi arasını bilinçli olarak ayırıyor ve şablon birimi düzeyinde çalışmayı destekliyor. Çözülmek istenen problemin özelliklerinin ve insanların kullanım alışkanlıklarının dikkate alındığını düşünüyorum.
Buna karşılık PHP'de standart çıktı doğrudan sayfanın bir parçası olur ve sunucu tarafı verisi ile HTML sayfası arasındaki sınır belirsizdir.
printedilen şey sonuç sayfasına aynen girer ve escape işlemini geliştiricinin açıkça yapması gerekir.htmlcharacterescapesfonksiyonunu tüm dış verilerin başına eklemek gerektiği şeklindeki tasarım insanlar tarafından iyi karşılanmadı. İnsanlar bilinçsizce bir şablon istiyordu, ancak PHP'de kullanıcının HTML sayfası üretme amacının dikkate alınmadığı görülüyor.Bu işlevin standart kütüphanede ya da dilin kendisinde yer almasının nedeni, PHP'nin ortam yapılandırması ve kod dağıtım biçimi düşünüldüğünde bunun en etkili yöntem olmasıdır. Geliştirme ortamı LAMP stack ile, işletim ortamı da web hosting yöntemiyle kalıplaşmış durumda ve insanlar FTP ile dosya atma yöntemine alışkın olduğundan ek paket sağlama imkânı genel amaçlı dillere göre daha düşüktür. Başlangıç seviyesindeki kullanıcılardan modül kurulumu yapmalarını istemek de mümkün değildir. Geriye kalan seçenekler sadece standart kütüphane ve standart dokümantasyondur.
> İnsanlar bilinçsizce şablon istiyordu, ancak PHP'de kullanıcının HTML sayfası üretme amacı dikkate alınmamış gibi görünüyor.
Buna çok katıldığımı söyleyemem.
PHP3 döneminde, yalnızca C API'lerini CGI üzerinden kolayca açığa çıkaran bir düzeydeyken, dediğiniz gibi şablon amaçlı kullanıldığını söylemek mümkün olabilir ama...
PHP 4.2'den itibaren ortam zaten yeterince genel amaçlı kullanımın mümkün olduğu bir seviyeye gelmişti.
Kodun CLI üzerinden çalıştırılmasının beklenebileceği bir ortam oluşmuştu ve önceki yorumda bahsettiğiniz, "Laravel 2007 civarında bağımsız bir proje olarak değil, dilin resmî özelliği olarak çıkmalıydı" şeklindeki ifade, o dönemdeki PHP yönelimiyle hiç uyuşmayan bir söylem.
2004'te yayımlanan PHP şablon motoru Smarty ve 2006'da yayımlanan PHP MVC framework'ü CodeIgniter gibi örneklerin varlığı, PHP'nin kendi başına bir şablon dili olmadığını tersinden kanıtlıyor; ayrıca bu şekilde kullanılmaması gerektiğine dair PHP ekosisteminde zaten toplumsal bir mutabakat oluştuğu da söylenebilir.
> Frontend framework'leri, sunucu taraflı şablon motorları vb. veriyle render edilebilen tüm içeriklere topluca HTML escape uygular ve yalnızca escape işlemi açıkça kaldırıldığında güvensiz biçimde çıktı üretir.
Önceki yorumdaki bu kısmın da PHP'nin zaman çizelgesiyle karşılaştırıldığında pek doğru olduğunu düşünmüyorum.
Django ilk kez 2005'te yayımlandığında ve sonrasındaki birkaç yıl boyunca HTML escaping varsayılan ayar değildi. Geliştiricinin escape filtresini bilinçli olarak eklemesi gerekiyordu. Bugün bile Python'da kullanılan jinja, hâlâ HTML escaping'i otomatik olarak yapmıyor.
Escape işlemini otomatik yapan yaklaşımın genel kabul gördüğü dönemde, PHP çoktan "şablon dili" kimliğini geride bırakmıştı. (O sırada PHP'yi düşünmeden kullanan kullanıcılar bunu istememiş olabilir; ama başka bir açıdan bakarsak, PHP'nin bu tür kullanıcıları yavaş yavaş dışlamaya karar verdiği de söylenebilir.)
PHP artık bu amaç için kullanılan bir dil olmadığından, PHP'de standart kütüphane ve dil düzeyinde böyle bir özelliğin varsayılan olarak uygulanması için hiçbir neden yoktu; genel amaçlı bir dil olarak çalışmak isteyen PHP açısından bakıldığında da, bahsettiğiniz
htmlcharacterescapesfonksiyonu zaten görevini yeterince yerine getiriyordu diye düşünüyorum.> Web hosting tarzı işletim ortamı standartlaşmış durumda ve FTP ile dosya atma yöntemine alışılmış olduğu için, ek paket sağlama imkânı genel amaçlı dillere kıyasla daha düşüktür.
Bu görüşe de pek katılmak zor. On yılı çok aşkın bir süredir git gibi araçlar gayet iyi kullanılıyordu. Hatta Docker yayımlandıktan hemen sonra bile Docker tabanlı dağıtım yeterince sık deneniyordu; bugün de hâlâ bu şekilde kullanılıyor.
Bahsettiğiniz noktaların çoğu, PHP'den çok PHP ile geliştirilmiş CMS'lerin üzerinde çalışırken anlam taşıyan şeyler gibi geliyor bana.
Bu ifadeyi kullanmayı çok sevmem ama, PHP geliştiricilerinin bile geliştirici saymadığı türden vakalar...
jinja’nın otomatik escape özelliği konusunda benim iddiam yanlıştı; sizin belirttiğiniz doğru.
> Yukarıdaki görüşe de büyük ölçüde katılmakta zorlanıyorum. Git vb. araçlar on yılı da aşkın bir süredir zaten çok iyi kullanılıyordu. Hatta Docker yayımlandıktan hemen sonra Docker kullanan dağıtım denemeleri de fazlasıyla yapıldı ve hâlâ bu şekilde kullanılıyor.
Benim PHP deneyimim 2014’te kaldı ve o zamanlar Docker yoktu. Git’i de çalışma biçimini değiştirmek gerektiği için devreye alamıyorduk. Gerçek çalışma ortamında böyle şeyleri devreye sokmak için ortak bir mutabakat olması gerekiyor ama benim durumumda bu mümkün değildi.
> Bu tür ifadeleri sevmem ama, PHP geliştiricilerine de geliştirici muamelesi yapılmayan türden bir durum...
Geriye dönüp bakınca, sanırım geliştirici muamelesi görmeyen insanların arasında çalışıyormuşum.
Örnek verdiğiniz Django’nun kimlik doğrulama, yetkilendirme, form doğrulama, DB migration araçları ve test araçlarının hepsi PHP’nin Laravel’inde de sunuluyor.
Kimlik doğrulama: https://laravel.com/docs/11.x/authentication
Yetkilendirme: https://laravel.com/docs/11.x/authorization
Form doğrulama: https://laravel.com/docs/11.x/validation
DB migration: https://laravel.com/docs/11.x/migrations
Test: https://laravel.com/docs/11.x/testing
Ayrıca, harici bir kütüphane ya da ücretli bir kütüphane olsa da,
mevcut DB şemasını model ve migration kodu olarak dışa aktarabilen ya da tersini de yapabilen araçlar da var,
CRUD UI içeren temiz bir back-office sunan https://nova.laravel.com/ da mevcut.
Django’nun sahip olduğu işlevlerin neredeyse tamamı Laravel’de de mevcut.
(Zaten ikisi de RoR’un konseptini devraldığı için, sundukları işlevlerin benzer olması kaçınılmaz diye düşünüyorum.)
Buna rağmen Django-Python’dan farklı olarak Laravel-PHP’de, önceki yorumumda bahsettiğim avantajlar ek olarak mevcut.
PHP’nin web uygulamaları için bir şablon dili olma iddiasıyla tasarlanmış bir dil olduğu inkâr edilemez bir gerçek,
ama modern PHP tarzının yerleşmesinin üzerinden neredeyse on yıl geçmişken onu hâlâ sadece bir şablon dili olarak görmek biraz haksızlık gibi geliyor bana.
Nova’ya verilen bağlantıya bakıp inceledim; bunun da ücretli lisanslı olduğu görülüyor. Proje eğitimlerinde açıkça belirtilip hemen kullanılabilen Django admin ile işlev olarak benzer olabilir, ama erişilebilirlik açısından arada bir fark var gibi görünüyor.
Ayrıca Laravel’in, açık kaynak katkıcıları tarafından değil de Rasmus ya da Zend gibi şirketler tarafından, 2011’de değil yaklaşık 2007’de, ayrı bir proje olarak değil resmi dil özelliği olarak çıkması gereken bir şey olduğunu düşünüyorum. Python 3’ün geriye dönük uyumluluğun bir kısmından vazgeçmesi nedeniyle benimsenmesinde aksaklıklar oldu ama bence PHP de 5 sürümü civarında büyük çaplı bir geriye dönük uyumluluk temizliği yapmalıydı. PHP’nin değişimi sanki her zaman çağın akışının biraz gerisinden geliyor gibi.
Artık kişisel olarak web geliştirmeye yeni başlayan bir konumda olmadığım için, PHP’yi seçmem söz konusu olmayacaktır.
Dili ve framework'ü sürekli karıştırıyorsunuz.
Aynı içeriği birden fazla yere yorum olarak yazmanızın gerekli olmadığını düşünüyorum. Dikkat çekmek mi istiyorsunuz?
Elbette eskisine göre daha iyi hale geliyor, ama bu saatten sonra PHP kullanmaktansa Node.js ya da Python kullanmanın daha çok yönlü kullanım alanı sunduğu görülüyor.
PHP artık berbat değil akımı geliyor
10 yıl boyunca PHP ekosisteminin, dağıtım biçiminin, çalışma modelinin, hata ayıklama yöntemlerinin vb. ne kadar iyileştiğine dair hiçbir değinme yok. PHP ile geliştirme yapmayı bilen insanların değişmesi en çok zaman alan ve en zor şey olduğu için, açıkçası pek de iyileşeceğine dair bir beklentim bile yok. Özellikle bağlantı verilen gönderi bir PHP serbest çalışanının pazarlama amaçlı blogu olduğundan, özellikle seçici biçimde yaklaşmak gerekiyor gibi görünüyor.
Son 10 yılda Composer paketleri (
node'dakinpmbenzeri dağıtım) açısından bakıldığında PHP kullanım istatistiklerinde PHP 5 ve altı tamamen yok oldu; PHP ekosistemi de çoktan Composer merkezli hale geldi.WordPress, GNU Board gibi bazı CMS'ler ise bundan tamamen kopuk durumda.
CMS'ler hariç ekosistemde durum yukarıdaki gibi.
PHP kullanan biri olarak, PHP hâlâ en kötü dil.
Çünkü diğer diller daha iyi hâle geldi.
Hacker News yorumu
Özet:
fopen()içinde hata kodu alınamaması gibi köklü meselelerdiPHP: kötü tasarımın bir fraktalı (Korece)
12 yıl önceki belge lol
2012'de yazılmış bir belgeyi hâlâ....
PHP'nin hiç gelişmeden 2012'deki o dönemi aynen koruyor olduğunu mu düşünüyorsunuz..?
Ama tabii, temelsiz şekilde ortaya çıkmış bir dil olduğunu inkâr etmek zor olur. Ha
Bahsedilen İngilizce belgenin çeviri bağlantısı burada..
PHP ne kadar kötü olursa olsun, herhalde o dönemin sorunlarını hâlâ korumuyordur.
Bakımını sürdürmek de ayrı bir sorun. Tasarım bu seviyeden itibaren zaten hatalıyken, sürüm yükseltip kalite arttı mı? Bu, geriye dönük uyumluluğu ciddi biçimde bozduğu için başlı başına bir sorun. Karşılaştırma operatörlerinden başlayarak her şey tuhaf; ne yapılabilir ki.
Görünüşe göre sadece Hacker News özetindeki 4. bağlantının Korece çevirisini paylaşmışlar haha