Adakah PHP bahasa pengaturcaraan yang paling teruk?

Saya mempunyai hampir dua puluh tahun pengalaman pengaturcaraan dan telah berkembang dalam pelbagai bahasa pengaturcaraan. Dalam kebanyakan pekerjaan yang saya ada dan dalam pekerjaan yang saya lakukan sekarang, saya sangat teruja untuk mempunyai PHP sebagai bahasa pengaturcaraan teras saya. Dari pertama kali saya mula bekerja dengan PHP, saya mendengar pelbagai jenis keluhan tentang PHP, tetapi pada masa yang sama saya juga melihat kuasa PHP.

PHP ialah sekurang-kurangnya bahasa pengaturcaraan yang menarik. Bahasa dan program yang dibina dengannya secara amnya termasuk dalam dua falsafah reka bentuk. Di sini, saya tidak bercakap tentang kitaran hayat pembangunan perisian seperti Waterfall atau Agile, tetapi idea asas tentang perisian yang sepatutnya. Idea ini dipanggil "Jalan yang Betul" dan "Lebih teruk adalah lebih baik."

PHP ialah satu lagi bahasa pengaturcaraan yang agak pelik. Apabila orang mengadu bahawa bahasa itu "menyakitkan", mereka tidak salah. Memang banyak keburukan bahasa ini. Pada masa itu, bahasa mempunyai masalah yang lebih dahsyat. Catatan blog yang mengejek PHP, "PHP: a fractal of bad design," memang mempunyai beberapa perkara yang sah, walaupun ia sudah lapuk semasa ia diterbitkan sembilan tahun lalu.

Walau bagaimanapun, pada masa yang sama, pembangun boleh menggunakan PHP untuk mencipta perisian "betul" secara struktur dan mengimport falsafah daripada bahasa lain yang dianggap sebagai amalan yang baik. Rangka kerja seperti Laminas dan Symfony menggunakan amalan terbaik pengaturcaraan berorientasikan objek, membenarkan pembangun menulis kod yang betul dari segi struktur menggunakan rangka kerja ini.

Bagaimanakah PHP melakukan ini? Ini kerana PHP adalah bahasa pengaturcaraan yang paling teruk.

Merancang Perisian

Pada tahun 1991, Richard P. Gabriel menerbitkan artikel "Lisp: Good News, Bad News, and How to Win Big 》(Lisp: Berita Baik, Berita Buruk, Cara Menang Besar). Hujah artikel ini ialah falsafah "lebih teruk adalah lebih baik" akan menjadi pilihan yang lebih baik apabila ia berkaitan dengan reka bentuk perisian dan umur panjang. Dia membuat kesimpulan ini kerana dia menyedari kemunculan dua sekolah pengaturcaraan yang berbeza, yang dia namakan "Gaya MIT/Standford," atau "Cara yang betul," dan "Gaya New Jersey," atau "lebih teruk adalah lebih baik."

Kedua-dua falsafah mempunyai matlamat yang sama tetapi berbeza dalam bidang utama. Kedua-dua gaya memfokuskan pada empat bidang utama falsafah falsafah: Kesederhanaan, Ketepatan, Ketekalan dan Kesempurnaan.

Gaya MIT diterangkan seperti ini:

• Kesederhanaan: Reka bentuk mestilah ringkas, sama ada pelaksanaan atau antara muka, ia mestilah ringkas. Sebagai perbandingan, adalah lebih penting untuk memastikan antara muka mudah.

• Ketepatan: Reka bentuk mestilah betul dalam semua aspek yang boleh diperhatikan. Jangan cuba membuat reka bentuk yang salah.

• Ketekalan: Reka bentuk mestilah tidak konsisten. Untuk memastikan konsistensi, anda boleh sedikit mengorbankan kesederhanaan dan kesempurnaan. Ketekalan dan ketepatan adalah sama penting.

• Kelengkapan: Reka bentuk mesti meliputi seberapa banyak situasi penting yang mungkin. Semua situasi yang dijangkakan mesti dilindungi. Kesempurnaan harus diutamakan daripada kesederhanaan.

Bagi gaya New Jersey, Gabriel berkata ia mentakrifkan matlamatnya sebagai:

• Kesederhanaan: Reka bentuk mestilah ringkas, tanpa mengira pelaksanaannya Kedua-dua antara muka mestilah mudah. Sebagai perbandingan, adalah lebih penting untuk memastikan pelaksanaannya mudah. Kesederhanaan adalah yang paling penting, dan tiada ciri lain yang sama pentingnya dengan memastikannya mudah.

• Ketepatan: Reka bentuk mestilah betul dalam semua aspek yang boleh diperhatikan. Tetapi ketepatan boleh dikorbankan sedikit demi kesederhanaan.

• Ketekalan: Reka bentuk mestilah tidak terlalu tidak konsisten. Dalam sesetengah kes, konsistensi boleh dikorbankan untuk kesederhanaan. Jika memperkenalkan situasi luar biasa ke dalam reka bentuk akan menjadikan pelaksanaannya rumit atau tidak konsisten, maka jangan pertimbangkan.

• Kelengkapan: Reka bentuk mesti meliputi seberapa banyak situasi penting yang mungkin. Semua situasi yang dijangkakan mesti dilindungi. Integriti boleh memberi laluan kepada mana-mana ciri lain. Malah, kesempurnaan mesti dikorbankan apabila kesederhanaan pelaksanaan terancam. Jika anda ingin memastikan perkara mudah, anda boleh mengorbankan konsistensi untuk kesempurnaan terutamanya konsistensi antara muka.

Kunci kepada perdebatan ini ialah menggunakan LISP dan C sebagai contoh mengapa "lebih teruk adalah lebih baik". Bagi pengaturcara LISP Gabriel, LISP ialah bahasa yang lebih baik daripada C, sepantas C, dan Common LISP telah mengambil masa bertahun-tahun untuk mereka bentuk, membangun dan menyeragamkan. Spesifikasi yang mentakrifkan bahasa menggunakan yang terbaik daripada semua LISP yang berbeza, dan persekitaran pembangunan moden adalah yang terbaik untuk pembangun LISP.

LISP adalah cara yang betul

LISP mewakili "cara yang betul" pembangunan perisian. LISP mudah untuk berinteraksi dan anda boleh berinteraksi dengannya dalam pelbagai cara. Ingin menghubungi LISP dari Fortran? Anda boleh memanggil LISP dari Fortran dan menghantar data masuk, dan sebaliknya. Anda boleh menggunakan semua ciri "mewah" moden LISP sambil bekerja dengan kod warisan.

LISP mempunyai reka bentuk yang konsisten berkat spesifikasinya. Jika anda melihat bahasa moden seperti Python, spesifikasi sangat membantu dalam menyediakan berbilang bahagian belakang dan penyusun, dan semuanya mentafsir atau menyusun kod dengan cara yang sama. Alat ini adalah yang terbaik, dan LISP pada tahun 1991 mempunyai semua keselesaan yang masih kita nikmati hari ini, seperti penyahpepijatan langkah, pemeriksaan data dan editor mewah.

Sebagai bahasa, LISP lengkap. Ia menampilkan lapisan pengaturcaraan berorientasikan objek lanjutan, warisan berbilang, objek kelas pertama, dan fungsi serta jenis. LISP nampaknya merupakan pembangun bahasa pengaturcaraan dalam fikiran.

Pada tahun 1991, bahasa pengaturcaraan seperti LISP mungkin berada dalam bentuk terbaik yang pernah ada. Ketepatan teknikal ini belum dibuktikan dengan penggunaan sebenar. Pembangun LISP semakin berkurangan. Reputasi luar LISP telah dihalang oleh akhbar negatif dan salah letak selama bertahun-tahun. Orang ramai tidak lagi menganggapnya sebagai cara untuk menyampaikan perisian kepada pengguna akhir.

Dari segi pembangunan, LISP selalunya mewakili banyak cita-cita yang sama seperti Big Design Up Front (BDUF). Jika anda pernah menggunakan kaedah reka bentuk seperti Model Air Terjun, anda akan menemui beberapa masalah. "Cara yang betul" memberi penekanan yang kuat pada konsistensi, ketepatan, dan memastikan setiap isu yang boleh difikirkan diambil kira.

LISP sendiri bukanlah satu bahasa, tetapi satu keluarga bahasa. Walaupun Common LISP direka untuk menjadi standard, pelaksanaan LISP itu sendiri wujud berdasarkan pelbagai tugas yang perlu dilakukan. Sebuah artikel di laman web Lockless Inc menunjukkan "pemecahan" ini sebagai salah satu faktor penentu kegagalan LISP akhirnya. Walaupun LISP mematuhi "cara yang betul" reka bentuk perisian, pemecahan ini mengakibatkan penyelenggaraan kod dan mudah alih terjejas.

C dan Unix adalah cara yang salah untuk pergi

Pada masa yang sama, disebabkan kemunculan Unix, bahasa C secara beransur-ansur menjadi kaedah pilihan untuk pembangunan perisian. C direka untuk Unix, dan Unix direka dalam C. Pembangunnya mempunyai pendirian reka bentuk yang berbeza daripada LISP MIT dan pengarangnya.

Pada tahun 1972, C telah direka bentuk untuk menjadi bahasa yang mudah. Menjelang tahun 1991, ia telah berubah sedikit, tetapi prinsip asas bahasa C tidak berubah. Beberapa ciri telah ditambah untuk memenuhi keperluan pembangun dan Unix. Kerana bahasanya mudah, menulis penyusun dan program adalah mudah. Walaupun bahasa itu tidak menghalang anda daripada melakukan pengaturcaraan yang kompleks, C mempunyai anggaran 50-80% daripada ciri yang diperlukan oleh pengaturcara berbanding LISP.

Walau bagaimanapun, bahasa C sangat mudah alih. Ia juga boleh dijalankan pada perkakasan kuasa yang lebih rendah daripada yang biasa digunakan dalam perisian dan persekitaran LISP. Faktor ini memungkinkan untuk menyusun dan menjalankan perisian pada julat mesin yang lebih luas. C dan Unix mudah digunakan, dan Gabriel berpendapat Unix dan C akan menjadi viral.

Bahasa C berkembang semasa Dennis Ritchie mereka bentuk dan membina Unix. Oleh kerana Bell Labs tidak dibenarkan memasuki medan komputer secara rasmi, Unix juga boleh diedarkan dengan mudah kepada pelbagai pengguna. Pengguna ini membantu menampal Unix untuk memenuhi keperluan mereka sendiri. Dennis Ritchie dapat menyusun tampalan ini mengikut keperluan tanpa perlu memikirkan keperluan tersebut terlebih dahulu.

Tidak seperti LISP, C masih banyak digunakan sehingga kini. Walaupun bahasa tafsiran peringkat tinggi seperti PHP, JavaScript, dan Python adalah pilihan pertama banyak pembangun, kebanyakan bahasa peringkat tinggi ini dibangunkan dalam C. Walaupun pesaing seperti Rust mula muncul, keupayaan untuk berjalan pada peranti kecil dan berkuasa rendah kekal sebagai kekuatan bahasa C.

PHP adalah yang paling teruk

Jadi perisian "worse is better" akan diterima dahulu, kedua Ia akan membuatkan pengguna kurang mengharapkan , dan ketiga, perisian akan terus dipertingkatkan sehingga ia hampir dengan "cara yang betul."

- Richard Gabrie

Beberapa tahun selepas pendedahan ini, Rasmus Lerdorf mula bekerja pada laman utama/jurubahasa borang peribadi, yang kini kita kenali sebagai PHP. PHP/FI lahir daripada keperluan Lerdorf untuk mengekalkan halaman utamanya dan berinteraksi dengan borang dan pangkalan data. PHP/FI tidak direka bentuk sebagai bahasa pengaturcaraan sebenar, tetapi sebagai lapisan skrip dan fungsi di atas bahasa C.

PHP sangat mudah

Reka bentuk mestilah ringkas, sama ada pelaksanaan atau antara muka.

PHP menggunakan bahasa C di bawah hud Seperti yang telah kami katakan sebelum ini, bahagian ini adalah yang "paling teruk". Walau bagaimanapun, ini juga membawa beberapa kelebihan, yang paling penting, bahasa asas yang lebih mudah yang menjadikannya lebih mudah untuk dilanjutkan. Walaupun Hack/HHVM mengambil pendekatan lebih C, PHP itu sendiri masih bahasa C.

Ia hanya mengambil masa beberapa jam untuk mempelajari struktur dalaman bahasa ini. Elizabeth Smith memberikan ceramah hebat tentang sambungan PHP yang merangkumi banyak perkara tentang kerja dalaman PHP. Bahasa itu sendiri menggunakan bahasa gaya C yang lain, yang bukan sahaja mudah dibaca, tetapi juga boleh ditukar kepada bahasa gaya C yang lain.

Kebanyakan antara muka PHP, atau perpustakaan standard, adalah sangat mudah, kerana kebanyakan fungsi teras hanyalah pembalut di sekeliling pelbagai perpustakaan bahasa C dan kemudian terdedah hampir tidak berubah. Walaupun berbuat demikian mengakibatkan beberapa ketidakkonsistenan dalam antara muka, ia menyediakan persekitaran yang biasa untuk pembangun yang datang dari C atau C++.

Bahasa PHP sangat tertumpu pada pembangunan web. Selalunya sangat mudah untuk mengekstrak konsep daripada HTTP dan mencari konsep yang serupa dalam bahasa. Ingin mengetahui maklumat pengepala permintaan? get_headers() akan memuaskan hati anda. Mendapatkan maklumat permintaan adalah semudah membaca pembolehubah global $_GET dan $_POST.

PHP mengekalkan antara muka pembangun yang ringkas dan mengekalkan struktur dalamannya semudah mungkin.

PHP (hampir) betul

Reka bentuk mestilah betul dalam semua aspek yang boleh diperhatikan. Tetapi ketepatan boleh dikorbankan sedikit demi kesederhanaan.

Di sini, PHP cenderung memilih "mudah" berbanding betul. Sebelum kemunculan HHVM, rupa dan ciri bahasa itu tidak diseragamkan. Jurubahasa Zend ialah spesifikasi itu sendiri, dan cara bahasa itu berkelakuan sentiasa "betul" (tidak termasuk ralat sebenar). Jika anda ingin menggantikan enjin PHP dengan sesuatu yang lain, anda mesti melaksanakan semua ciri enjin sedia ada.

Parameter fungsi LAX dan jenis pulangan untuk banyak fungsi teras menjadikan kerja sistem lebih mudah. Fungsi seperti strpos() yang boleh mengembalikan integer atau boolean adalah lebih mudah dikendalikan daripada kaedah yang direka bentuk dengan ketat untuk mengembalikan integer atau membuang pengecualian.

Melihat perkembangan bahasa PHP, hampir semua ciri baharu adalah berdasarkan apa yang diperlukan oleh pembangun, dan bukannya idea serius "ia mesti diperbaiki kerana ia salah". Memfokuskan lebih pada jenis yang ketat dan ralat pengecualian adalah cara yang lebih betul untuk melakukan sesuatu. Walau bagaimanapun, terdapat juga perkara seperti fungsi anak panah pendek, sifat dan penghitungan yang ingin digunakan oleh pembangun untuk memudahkan kod mereka.

PHP tidak memerlukan konsistensi

Reka bentuk mestilah tidak terlalu tidak konsisten. Dalam sesetengah kes, konsistensi boleh dikorbankan demi kesederhanaan.

Saya tidak akan berpura-pura bahawa PHP adalah konsisten, tetapi ia cukup konsisten. Orang ramai mungkin mengadu tentang susunan hujah jarum/timbunan jerami apabila ia berkaitan dengan fungsi tatasusunan vs. rentetan. Walau bagaimanapun, secara amnya, fungsi tatasusunan adalah konsisten, dan fungsi rentetan juga konsisten. Lebih mudah untuk konsisten dengan perpustakaan C yang mendasari daripada dalam bahasa.

PHP sebaliknya cukup konsisten. Seperti yang saya nyatakan dengan strpos(), PHP cenderung untuk mengembalikan FALSE secara konsisten untuk fungsi yang menghadapi ralat. Ini tidak semestinya betul, tetapi ia konsisten. Nama fungsi bergaris bawah dan bukan garis bawah biasanya sepadan dengan perpustakaan asasnya.

Bahasa PHP mengorbankan konsistensi untuk kesederhanaan, tetapi walaupun tanpa spesifikasi ini, ia masih berusaha untuk konsisten di mana ia masuk akal.

PHP adalah selengkap yang diperlukan

Reka bentuk mesti meliputi seberapa banyak situasi penting yang mungkin.

PHP lengkap bila-bila masa anda memerlukannya untuk tugas reka bentuk yang paling mencabar: menulis aplikasi web. PHP tidak pernah direka untuk menjadi bahasa yang boleh digunakan untuk semua masalah dalam dunia pengaturcaraan. Namun, kesederhanaannya menjadikannya boleh digunakan di luar Web. Tujuan asal PHP adalah untuk menyediakan fungsi paling asas untuk pengaturcaraan web, dan trend ini berterusan hari ini.

Pengubahsuaian kepada bahasa teras selalunya didorong oleh keperluan pembangun. Seluruh komuniti mencadangkan pengubahsuaian, dan kemudian komuniti mengundi untuk memutuskan sama ada ciri baharu itu ditolak, diubah atau diterima. Banyak inovasi dalam bahasa berpunca daripada keperluan untuk menyelesaikan sesuatu dengan cepat. Walaupun apabila kita menyerap ciri daripada bahasa lain, ini kerana ia menjadikan pembangunan kita lebih mudah, jarang sekali kerana bahasa lain melakukannya "dengan lebih betul."

Hari ini, anda boleh membangunkan aplikasi web menggunakan PHP. Lima tahun dari sekarang, anda masih boleh membangunkan aplikasi web dalam PHP, hanya dengan beberapa ciri baharu. Namun, keutuhan bahasa itu sendiri sudah memadai untuk keperluan masa kini. Kami sentiasa boleh mengubah suai bahasa atau menambah ciri baharu padanya jika perlu pada masa hadapan.

Adakah lebih teruk lebih baik?

Gabriel mengakui bahawa falsafah "lebih buruk adalah lebih baik" merujuk kepada reka bentuk yang kelihatan buruk dan mungkin tidak boleh dianggap sebagai pilihan yang lebih baik. Satu-satunya masalah ialah apabila dia melihat kedua-dua falsafah, "lebih teruk adalah lebih baik" masih menjadi pilihan yang lebih fleksibel, berbanding dengan falsafah reka bentuk MIT/"cara yang betul", "dengan ciri kemandirian yang lebih baik". Jika kita melihat PHP, kita boleh mengesahkan idea bahawa "lebih teruk adalah lebih baik".

Selama bertahun-tahun, Gabriel mengakui bahawa dia ragu-ragu antara cara yang lebih baik. Komuniti PHP telah berdebat sama ada kita perlu melakukan perkara yang betul atau terus melakukan perkara dengan mudah. Kami mempunyai rangka kerja seperti Laminas, yang membina perpustakaan dengan cara sains komputer klasik, dan kemudian kami mempunyai rangka kerja seperti Laravel, yang memfokuskan pada pengalaman dan kelajuan pembangun. PHP itu sendiri adalah kedua-duanya.

Lain kali anda mendengar seseorang mengkritik PHP, teruskan sahaja. Teruk betul bahasanya. Tetapi dalam banyak cara, jangka hayat PHP dan penggunaan meluas adalah bukti fakta bahawa melakukan sesuatu dengan "cara yang betul" tidak selalunya lebih baik daripada cara "paling teruk". Apabila seseorang mengadu tentang rangka kerja yang anda gunakan, fahami bahawa ia tidak penting dalam jangka masa panjang. Pilih falsafah reka bentuk yang anda fikir sesuai untuk anda, dan terima hakikat bahawa lebih teruk mungkin lebih baik.

Pautan asal: https://www.phparch.com/2021/09/education-station-php-is-the-worst/

Pengarang asal: Chris Tankersley

Mengenai pengarang:

Chris Tankersley memakai banyak topi: suami, bapa, pengarang, pembesar suara, hos podcast dan pembangun PHP. Chris telah menggunakan banyak rangka kerja dan bahasa yang berbeza sepanjang kerjaya pengaturcaraannya selama 12 tahun, tetapi dia menghabiskan sebahagian besar harinya bekerja dengan PHP dan Python. Beliau ialah pengarang Docker for Developers dan bekerjasama dengan syarikat dan pembangun untuk menyepadukan bekas ke dalam aliran kerja mereka.

Pembelajaran yang disyorkan: "Tutorial Video PHP"